Security Links and References

To get a level of how many data breaches are happening Breach Level Index provides this information, along with many other statistics

Need to check if you have an email account that has been compromised in a data breach when check out Have I Been Pwned to check if you have been compromised and also Signup to get email notifications

For a collection of Cryptography APIs in one library

HSM hardware

Azure Resource Manager Templates Tips and Tricks for a Application Service

Over the past week, I spent some time automating Azure App Service infrastructure with Azure Resource Manager (ARM) templates. I discovered a few tips and tricks along the way that I’ll describe in detail below…

  • Take an environment name as a parameter
  • Create sticky slot settings
  • Variables aren’t just for strings
  • Change the time zone of your web app

Big thanks to David Ebbo’s talk at BUILD and his sample “WebAppManyFeatures” template; they are super handy resources for anyone who is working on writing their own ARM templates.

Environment Name Parameter

ARM templates are useful for creating the entire infrastructure for an application. Often this means creating infrastructure for each deployment environment (Dev, QA, Production, etc). Instead of passing in names for the service plans and web apps, I find it useful to pass in a name for the environment and use it as a suffix for all the names. This way we can easily use the same template to set up any environment.

    // ...
    "parameters": {
        "environmentName": {
            "type": "string"
    "variables": {
            "[concat('awesomeserviceplan-', parameters('environmentName'))]",
            "[concat('awesomesite-', parameters('environmentname'))]"
    // ...

In the above example, if we pass in “dev” as the,environmentName we get “awesomeserviceplan-dev” and “awesomesite-dev” as our resource names.

Sticky Slot Settings

App settings and connection strings for a Web App slot can be marked as a “slot setting” (i.e., the setting is sticky to the slot). It’s not well documented how to specify sticky slot settings in an ARM template. It turns out we can do this using a config resource section called “slotconfignames” on the production site. Simply list the app setting and connection string keys that need to stick to the slot:

    "apiVersion": "2015-08-01",
    "name": "slotconfignames",
    "type": "config",
    "dependsOn": [
        "[resourceId('Microsoft.Web/Sites', variables('siteName'))]"
    "properties": {
        "connectionStringNames": [ "ConnString1" ],
        "appSettingNames": [ "AppSettingKey1", "AppSettingKey2" ]

Here’s how it’ll look like in the portal:

Object Variables

Variables are not only useful for declaring text that is used in multiple places; they can be objects too! This is especially handy for settings that apply to multiple Web Apps in the template.

    // ...
    "variables": {
        "siteProperties": {
            "phpVersion": "5.5",
            "netFrameworkVersion": "v4.0",
            "use32BitWorkerProcess": false, /* 64-bit platform */
            "webSocketsEnabled": true,
            "alwaysOn": true,
            "requestTracingEnabled": true, /* Failed request tracing, aka 'freb' */
            "httpLoggingEnabled": true, /* IIS logs (aka Web server logging) */
            "logsDirectorySizeLimit": 40, /* 40 MB limit for IIS logs */
            "detailedErrorLoggingEnabled": true, /* Detailed error messages  */
            "remoteDebuggingEnabled": true,
            "remoteDebuggingVersion": "VS2013",
            "defaultDocuments": [
    // ...

And now we can use the siteProperties variable for the production site as well as its staging slot:

    "apiVersion": "2015-08-01",
    "name": "[variables('siteName')]",
    "type": "Microsoft.Web/sites",
    "location": "[parameters('siteLocation')]",
    "dependsOn": [
        "[resourceId('Microsoft.Web/serverfarms', variables('appServicePlanName'))]"
    "properties": {
        "serverFarmId": "[variables('appServicePlanName')]"
    "resources": [
            "apiVersion": "2015-08-01",
            "name": "web",
            "type": "config",
            "dependsOn": [
                "[resourceId('Microsoft.Web/Sites', variables('siteName'))]"
            "properties": "[variables('siteProperties')]"
            "apiVersion": "2015-08-01",
            "name": "Staging",
            "type": "slots",
            "location": "[parameters('siteLocation')]",
            "dependsOn": [
                "[resourceId('Microsoft.Web/Sites', variables('siteName'))]"
            "resources": [
                    "apiVersion": "2015-08-01",
                    "name": "web",
                    "type": "config",
                    "dependsOn": [
                        "[resourceId('Microsoft.Web/Sites/Slots', variables('siteName'), 'Staging')]"
                    "properties": "[variables('siteProperties')]"

Custom Time Zone

There’s a little-known setting in Azure App Service that allows you to set the time zone on a per-app basis. It is done by creating an app setting called WEBSITE_TIME_ZONE in the portal. It means we can also do this in an ARM template:

    "apiVersion": "2015-08-01",
    "name": "appsettings",
    "type": "config",
    "dependsOn": [
        "[resourceId('Microsoft.Web/Sites', variables('siteName'))]"
    "properties": {
        "WEBSITE_TIME_ZONE": "Pacific Standard Time"

For more information on the time zone setting, check out this article.

Source code: WebAppManyFeatures.json

Allow access to Azure services, what does this actually mean?

I did some quick research on the SQL Server Firewall “Allow Access to Azure Services” option in Azure today.

And I sorry to say that my fears were right, that by setting this option does pose a significant security risk and leaves the SQL Server vulnerable.

Here is the extract of the article I found from Gaurav Hind at Microsoft

Access within Azure: This can be toggled by “Allow access to Azure services” Yes/No button on the portal (Firewall settings page). Please note, enabling this feature would allow any traffic from resources/services hosted in Azure (not just your Azure subscription) to access the database.

The big question now is how do you plug this gap in the firewall?  One possible solution is to build a virtual network within Azure or Filter network traffic with network security groups, this is beyond the scope of this article.

Comparing SecureStrings

After writing about SecureStrings, you soon come to realise that holding the secret information you are going to have to make some comparisons at some point. For example, if you need to check a password.

The important thing to remember is not to expose the password as text or hold it in memory for anyone or anything to sniff it out.

This code snippet does the job, but it what it does expose is a Timing Attack, but we will deal with that issue another day.

public static bool IsEqualTo(this SecureString ss1, SecureString ss2)
 if (ss1 == null)
 throw new ArgumentNullException("s1");

if (ss2 == null)
 throw new ArgumentNullException("s2");

if (ss1.Length != ss2.Length)
 return false;

IntPtr bstr1 = IntPtr.Zero;
 IntPtr bstr2 = IntPtr.Zero;
 bstr1 = Marshal.SecureStringToBSTR(ss1);
 bstr2 = Marshal.SecureStringToBSTR(ss2);

int length1 = Marshal.ReadInt32(bstr1, -4);

for (int x = 0; x < length1; ++x)
 byte b1 = Marshal.ReadByte(bstr1, x);
 byte b2 = Marshal.ReadByte(bstr2, x);
 if (b1 != b2) return false;
 return true;
 if (bstr2 != IntPtr.Zero) Marshal.ZeroFreeBSTR(bstr2);
 if (bstr1 != IntPtr.Zero) Marshal.ZeroFreeBSTR(bstr1);



I’ve come across a class in the System.Security namespace that is often overlooked. The class is SecureString. In this post, I will go over what SecureString is and why it is needed.

Have you ever come across these scenarios before?

  • A password appears in a log file accidentally.
  • A password is being shown at somewhere – once a GUI did show a command line of application that was being run, and the command line consisted of the password.
  • Using memory profiler to profile software with your colleague. Colleague sees your password in memory.
  • Using RedGate software that could capture the “value” of local variables in case of exceptions, amazingly useful. Though, I can imagine that it will log “string passwords” accidentally.
  • A crash dump that includes string password.

Do you know how to avoid all these problems? SecureString. It makes sure you don’t make silly mistakes as such. How does it avoid it? By making sure that password is encrypted in unmanaged memory and the real value can be only accessed when you are 90% sure what you’re doing.

In the sense, SecureString works pretty easily:

  1. Everything is encrypted
  2. User calls AppendChar
  3. Decrypt everything in UNMANAGED MEMORY and add the character
  4. Encrypt everything again in UNMANAGED MEMORY.

What if the user has access to your computer? Would a virus be able to get access to all the SecureStrings? Yes. All you need to do is hook yourself into RtlEncryptMemory then decrypt the memory, and you will get the location of the unencrypted memory address, and read it out. Voila! In fact, you could make a virus that will continuously scan for usage of SecureString and log all the activities with it. I am not saying it will be an easy task, but it can be done. As you can see, the “powerfulness” of SecureString is completely gone once there’s a user/virus on your system.

You have few points in your post. Sure, if you use some of the UI controls that hold “string password” internally, using actual SecureString is not that useful.

The bottom line is; if you have sensitive data(passwords, credit cards, ..), use SecureString. This is what C# Framework is following. For example, NetworkCredential class stores password as SecureString. If you look this, you can see over ~80 different usages in .NET framework of SecureString.

There are many cases when you have to convert SecureString to string because some API expects it.

The usual problem is either:

  • The API is GENERIC. It does not know that there’s a sensitive data.
  • The API knows that it’s dealing with sensitive data and uses “string” – that’s just bad design.

You raised a good point: what happens when you convert SecureString to a string? That can only happen because of the first point. Eg the API does not know that it’s sensitive data. I have personally not seen that happening. Getting string out of SecureString is not that simple.

It’s not simple for a simple reason; it was never intended to let the user convert SecureString to string, as you stated: GC will kick in. If you see yourself doing that, you need to step back and ask yourself: Why am I even doing this, or do I need this, why?

You can always extend the SecureString class with an extension method, such as ToEncryptedString(__SERVER__PUBLIC_KEY), which gives you a string instance of SecureString that is encrypted using server’s public key. The only server can then decrypt it. Problem solved, GC will never see the “original” string, as you never expose it in managed memory. This is precisely what is being done in PSRemotingCryptoHelper (EncryptSecureStringCore(SecureString secureString)).

And as something very almost-related: Mono SecureString does not encrypt at all. The implementation has been commented out because ..wait for it. “It somehow causes nunit test breakage”, which brings to my last point:

Not supported everywhere is SecureString. If the platform/architecture does not support SecureString, you’ll get an exception. The recommended list of deployment platforms is documentation.

Using SecureString for Sensitive Data

The standard System.String class has never been a very secure solution for storing sensitive strings such as passwords or credit card numbers. Using a string for this purposes has numerous problems including it’s not pinned, so the garbage collector can move it around and will leave several copies in memory, it’s not encrypted, so anyone who can read your processor’s memory will be able to see the values of the string easily. Also, if your process gets swapped out to disk, the unencrypted contents of the string will be sitting in your swap file. And it’s not mutable, so whenever you need to modify it there will be an old version and the new version both in memory.

Since it’s not mutable, there’s no effective way to clear it out when you’re done using it. Secure strings are held in encrypted memory by the CLR using the Data Protection API, or DPAPI, and they’re only unencrypted when they are accessed.  This limits the amount of time that your string is in plain text for an attacker to see.

The garbage collector will not move the encrypted string around in memory, so you never have to worry about multiple copies of your string sitting in your address space, unless you make copies of those.

SecureString also implements IDisposable, and when it’s disposed of or finalised if you forget to dispose of it, the memory that was used to hold your encrypted string will be zeroed out.

They also provide a feature that lets you lock them down as read only preventing other code from modifying your string.

You can create a secure string with a pointer to a character array and a length of that array. When constructed this way, the secure string will make a copy of your array, allowing you to zero out your insecure copy.

A secure string can also be constructed without an existing character array, and the data can be copied in one character at a time.

One important thing to note though is that SecureString shouldn’t be used as a blanket replacement for System.String, it should only be used in places where you need to store sensitive information that you do not want to spread around in memory for longer than is required.

To add data or modify data in your string, standard operations are provided. For instance, you’ll find an AppendChar, InsertAt, RemoveAt, and SetAt methods. MakeReadOnly and IsReadOnly allows you to lock down the secure string. Clear, Dispose, and the finaliser takes care of removing any trace of the safe string from memory.

The main idea with SecureString is that you would never store a password or other textual secret in plain text. Unfortunately, SecureString was introduced into the framework only after plenty of APIs were built and shipped using passwords stored in a string, such as the System.Net.NetworkCredential. So any application that must use these APIs had no option but to convert secure strings to strings.

However, the SecureString class itself doesn’t provide any method to get back a plain string with its content, precisely to discourage this type of usage. What a developer has to do is use functions from the System.Runtime.InteropServices.Marshal to get a native buffer with the plain string, marshal a value into managed string, and then very importantly free the native buffer. The best implementation to get a string out of a secure string is to use a try/finally block to free the native buffer.

Here is a sample application showing how you can use SecureString, please remember in production do not use the SecureString to String as this just does not make sense and would make it insecure.


Here is a short method to convert a string to a SecureString

public static SecureString ToSecureString(this string source)
 if (string.IsNullOrWhiteSpace(source))
 return null;
 SecureString result = new SecureString();
 foreach (char c in source.ToCharArray())
 return result;

Raising Multiple Exceptions with AggregateException

There are occasions where you are aware of many exceptions within your code that you want to raise together in one go. Perhaps your system makes a service call to a middleware orchestration component that potentially returns many exceptions detailed in its response, or another scenario might be a batch processing task dealing with many items in one process that require you to collate all exceptions until the end and then throw them together.

Let us look at the batch scenario in more detail. In this situation, if you raised the first exception that you found it would exit the method without processing the remaining items. Alternatively, you could store the exception information in a variable of some sort and once all the elements are processed using the information to construct an exception and throw it. While this approach works, there are some drawbacks. There is the extra effort required to create a viable storage container to hold the exception information, and this may mean modifying existing code not to throw an exception but instead to log the details in this new ‘exception detail helper class’. This solution also lacks the additional benefits you get with creating an exception then, for example, the numerous intrinsic properties that exist within Exception objects that provide valuable additional context information to support the message within the exception. Even when all the relevant information has been collated into a single exception class, then you are still left with one exception holding all that information when you may need to handle the exceptions individually and pass them off to existing error handling frameworks which rely on a type deriving from Exception.

Luckily included in .Net Framework 4.0 is the simple but very useful AggregateException class which lives in the System namespace (within mscorlib.dll). It was created to use the Task Parallel Library, and its use within that library is described on MSDN here. Don’t think that is it’s only used though, as it can be put to good use within your code in situations like those described above where you need to throw many exceptions, so let’s see what it offers.

The AggregateException class is an exception type, inheriting from System.Exception, that acts a wrapper for a collection of child exceptions. Within your code, you can create instances of any exception based type and add them to the AggregateException’s collection. The idea is a simple one, but the AggregateException’s beauty comes in the implementation of this simplicity. As it is a regular exception class, it can handle in the usual way by existing code but also as a unique exception collection by the particular system that cares about all the exceptions nested within its bowels.

The class accepts the child exceptions on one of its seven constructors and then exposes them through its InnerExceptions property. Unfortunately, this is a read-only collection, and so it is not possible to add inner exceptions to the AggregateException after it has instantiated (which would have been nice) and so you will need to store your exceptions in a collection until you’re ready to create the Aggregate and throw it:

// create a collection container to hold exceptions List<Exception> exceptions = new List<Exception>(); // do some stuff here ........ // we have an exception with an innerexception, so add it to the list exceptions.Add(new TimeoutException("It timed out", new ArgumentException("ID missing"))); // do more stuff ..... // Another exception, add to list exceptions.Add(new NotImplementedException("Somethings not implemented")); // all done, now create the AggregateException and throw it AggregateException aggEx = new AggregateException(exceptions); throw aggEx;

The method you use to store the exceptions is up to you as long as you have them all ready at the time you create the AggregateException class. Seven constructors are allowing you to pass combinations of nothing, a string message, collections or arrays of inner exceptions.

Once created you interact with the class as you would any other exception type:

try {    // do task } catch (AggregateException ex) {    // handle it  }

The key as it means that you can make use of existing code and patterns for handling exceptions within your (or third parties) codebase.

In addition to the general Exception members, the class exposes a few custom ones. The common InnerException property is there for compatibility, and this appears to return the first exception added to the AggregateException class via the constructor, so in the example above it would be the TimeoutException instance. All of the child exceptions expose via the InnerExceptions read-only collection property (as shown below).

The Flatten() method is another custom property that might prove useful if you find the need to nest Exceptions as inner exceptions within several AggregateExceptions. The method will iterate the InnerExceptions collection, and if it finds AggregateExceptions nested as InnerExceptions, it will promote their child exceptions to the parent level. As you can see in this example:

AggregateException aggExInner = 
 new AggregateException("inner AggEx", new TimeoutException());
AggregateException aggExOuter1 = 
 new AggregateException("outer 1 AggEx", aggExInner);
AggregateException aggExOuter2 = 
 new AggregateException("outer 2 AggEx", new ArgumentException());
AggregateException aggExMaster =
 new AggregateException(aggExOuter1, aggExOuter2);

If we create this structure above of AggregrateExceptions with inner exceptions of TimeoutException and ArgumentException then the InnerExceptions property of the parent AggregateException (i.e. aggExMaster) shows, as expected, two objects, both being of type AggregrateException and both containing child exceptions of their own:

But if we call Flatten()…

AggregateException aggExFlatterX = aggExMaster.Flatten();

…we get a new ArgumentException instance returned that contains still two objects, but this time the AggregrateException objects have gone, and we have the two child exceptions of TimeoutException and ArgumentException:

A useful feature to discard the AggregateException containers (which are effectively just packaging) and expose the real meat, i.e. the real exceptions that have been thrown and needs to be addressed.

If you’re wondering how the ToString() is implemented then the aggExMaster object in the examples above (without flattening) produces this:

System.AggregateException: One or more errors occurred. ---> System.AggregateException
: outer 1 AggEx ---> System.AggregateException: inner AggEx ---> 
System.TimeoutException: The operation has timed out. --- End of inner exception 
stack trace --- --- End of inner exception stack trace --- --- End of inner exception 
stack trace ------> (Inner Exception #0) System.AggregateException: outer 1 AggEx ---> 
System.AggregateException: inner AggEx ---> System.TimeoutException: The operation
 has timed out. --- End of inner exception stack trace --- --- End of inner 
exception stack trace ------> (Inner Exception #0) System.AggregateException: inner
AggEx ---> System.TimeoutException: The operation has timed out. --- End of inner 
exception stack trace ------> (Inner Exception #0) System.TimeoutException: The 
operation has timed out.<---<---<------> (Inner Exception #1) System.AggregateException
: outer 2 AggEx --- System.ArgumentException: Value does not fall within the expected
 range. --- End of inner exception stack trace ------> (Inner Exception #0) 
System.ArgumentException: Value does not fall within the expected range.

As you can see the data has been formatted in a neat and convenient way for readability, with separators between the inner exceptions.

In summary, this is a very useful class to be aware of and have in your arsenal whether you are dealing with the Parallel Tasks Library or you just need to manage multiple exceptions. I like simple and neat solutions, and to me, this is a good example of that philosophy.

Orginal Article

Using MongoDB

If you want to setup MongoDB with C#, then the best option is to follow the getting started guide on the MongoDB website

You can install the NuGet package for MongoDB by typing into the Package Manager Console

  • “Install-Package MongoDB.Driver”

Although MongoDB does provide an example that you can work through, I did find that the MoveNextAsync command is no longer supported and the case fails.

I built a simple application that uses MongoDB CRUD application that works very well to show how it can be implemented.


Here is a helpful MongoDB tool to administer your Mongo database, Robomogo

On my searching to find good source of material I came across this nice video demo here

Custom Configuration in your config

This post is to show how to setup a customised configuration section in your app.config or web.conifg of your .NET application

I have written an article on this before, back in 2008, but things have moved on in the libraries and this is the latest and easiest way to create your own customised configuration.

We just need to define our class, inherit from System.Configuration.ConfigurationSection, and add a property per setting we wish to store.

using System;
using System.Configuration;

public class BlogSettings : ConfigurationSection
 private static BlogSettings settings = ConfigurationManager.GetSection("BlogSettings") as BlogSettings;
 public static BlogSettings Settings
 return settings;

 [ConfigurationProperty("frontPagePostCount" , DefaultValue = 20 , IsRequired = false)]
 [IntegerValidator(MinValue = 1 , MaxValue = 100)]
 public int FrontPagePostCount
 get { return (int)this["frontPagePostCount"]; }
 set { this["frontPagePostCount"] = value; }

 [ConfigurationProperty("title" , IsRequired=true)]
 public string Title
 get { return (string)this["title"]; }
 set { this["title"] = value; }

Notice that you use an indexed property to store and retrieve each property value.

Also not a static property named Settings for convenience.

Add your new configuration section to web.config (or app.config).

 <section name="BlogSettings" type="Fully.Qualified.TypeName.BlogSettings, 
 AssemblyName" />
 title="You’ve Been Haacked" />

And to access the new configuration using code it is as simple as:

string title = BlogSettings.Settings.Title;
Response.Write(title); //it works!!!

Here is the source code: Configuration Example

Another article that goes into this in a lot more details can be found on Code Project – Unraveling the Mysteries of .NET 2.0 Configuration

Azure Resource Manager Compute Templates

Things have moved forward in the Microsoft’s Azure cloud platform since I very first started using Azure.  One thing is for sure is that the number of services available has grown and with this growth comes the responsibility of ensuring that you can successfully deploy what you have built with the minimum about of trouble in the quickest possible time.  Along came the Azure Resource Manager (ARM) which is the service used to provision resources in your Azure subscription. It was first announced at Build 2014 when the new Azure portal ( was announced and provides a new set of JSON API’s that are used to provision resources. Before ARM, developers and IT professionals used the Azure Service Management API and the old portal ( to provision resources. Both portals and sets support the of API’s. However, going forward you should be using ARM, the new API’s, and the new Azure portal to provision and manage your Azure resources.

Azure Friday has a nice easy overview of the Azure Resource Manager.  Scott talks to Mahesh Thiagarajan about the new Azure JSON-based APIs for Azure that now include Compute, Network, and Storage. Orchestrating large system deployments is easier and more declarative than ever.


The Benefits of using the Azure Resource Manager

There are many benefits of ARM that the first Service Management API’s (and old portal) could not deliver. The advantages that ARM provides can be broken down into a few areas:

Declaratively Provision Resources

Azure Resouce Management provides us with a way to describe resources in a resource group using JSON documents.  There are many resource groups, for example, Web App, Storage Account, SQL Database. In the JSON document, you can describe the properties for each of the resources such as the type of storage account, the size of the SQL Database, and settings for the Web App; there are many more options available. The advantage here is that we can describe the environment we want and send that to Azure Resource Management to make it happen.

Smarter and Faster Provisioning of Resources

Before ARM, you had to provision resources independently to support your application, and it was up to you to figure dependencies between resources and accommodate for these in your deployment scripts.

ARM is also able to determine when it can provision resources simultaneously allow for faster provisioning of all the resources described in the resource group is achieved.

Resource Groups as a Unit of Management

Before ARM, the relationship between resources (i.e. a web app and a database) was something you had to manage yourself. Include trying to compute costs across multiple resources to determine the all-up costs for an application. In the ARM era, since the resource group containing the resources for your application are a single unit of deployment, the resource group also becomes a unit of management. By resource grouping it enables you to do things like determining costs for the entire resource group (and all he resources within), making accounting and chargebacks easier to manage.

Before ARM, if you wanted to enable a user or group of users to manage the resources for a particular application, then you had to make them a co-administrator on your Azure Subscription. The users have full capability to add, delete, and modify any resource in the subscription, not just the resources for that application. With ARM, you can configure Role-Based Access Control for resources and resource groups, enabling you to assign management permissions to only the resource group for only the users that need access to manage it. When those users sign-in to Azure they will be able to see the resource group you gave them access to but not the rest of the resources in your subscription. You can even assign Role-Based Access Control permissions to individual resources if you needed to.

Idempotent Provisioning of Resources

Post ARM, automating the provisioning of resources meant that you had to account for situations where some, but not all, of your resources, would be successfully provisioned.  With ARM, when you send it the JSON document describing your environment, ARM knows which resources already exist and which ones do not and will provision only the resources missing to complete the resource group.


The Azure portal is an excellent way to get started using Azure Resource Manager with nothing more than your browser. When you create resources using the Azure portal ( you are using ARM. Eventually, you will need to write a deployment template that describes all the resources you want ARM to provision. And to be scalable, you will need to automate the deployment. You could start with something from the Azure Quick start Templates, but at some point, you will likely need (or want) to build your deployment template from scratch. For this, Visual Studio and PowerShell are the two tools are strongly recommended.

Visual Studio

When it is time to write your ARM deployment templates, you will find that Visual Studio and the Azure Tools delivers an incredible experience that includes JSON IntelliSense in the editor and a JSON outline tool to visualise the resources. Writing ARM deployment templates is not a trivial task. By using Visual Studio and the Azure Tools, you will be able to create deployment templates from scratch in a matter of minutes.

A version of the Azure Tools SDK is available for  VS 2015. The Azure Tools provides an Azure Resource Group project template to get you started as shown below. In subsequent posts, I’ll be demonstrating how to use this project template.


The project template mentioned in the previous section generates a PowerShell deployment script that can be used to send your deployment to ARM in an automated manner. The script uses the latest Azure “RM” Cmdlets that you can download and install from here. Most of the code in the deployment script handles uploading artefacts that ARM may need to deploy your environment. For example, if your deployment template describes a virtual machine that requires a DSC extension to add additional configuration to the VM after Azure has created it, then the DSC package (zip file) would need to be generated and uploaded to a storage account for ARM to use while it is provisioning the VM. But, if you scroll down past all that to the bottom of the script file you will see two commands in the script (shown below).

The first command, New-AzureRmResourceGroup, only creates the resource group using a resource group name that you provide.

The second command, New-AzureRmResourceGroupDeployment, pushes your deployment template and parameters for the deployment template to ARM. After ARM receives the files, it starts provisioning the resources described in your deployment template.

A workflow diagram of how these tools are used to deploy an environment using Azure Resource Manager is shown here.

In this post, We’ve introduced Azure Resource Manager and highlighted some significant advantages it brings to the platform. Concluded by adding a couple of tools you should consider using to author your deployment templates.

Original post by Rick Rainey