Role Based Access Control is Azure’s method for setting permissions on resources to control who can manage and administer these resources. Each type of Azure resource has a number of permissions that can be set on it, and these permissions can be grouped into roles that can be applied to users or groups of users to grant rights to manage resources. Out of the box Azure comes with a large number of pre-defined roles for common workloads.

Don’t forget to check out the other parts in this series: Part 1 – Version Control Part 2 – Testing Part 3- Build Defining Infrastructure as Code is becoming prevalent in all areas of IT, but none more so than in the cloud. Be this Azure Resource Manager Templates, AWS Cloudformation or third party tools like Terraform. Once you’ve gone down this route, you open up the ability to treat your infrastructure code like any other code, and because it’s just code you can now leverage some of the tools developers have been using for years in their software lifecycle.

Microsoft recently announced the introduction of Azure Free Accounts, these are credit and resources that are free for a certain time period. This is aimed at competing with AWS free tier and similar offerings. Before we take a look at what is on offer, there are a few caveats to check to see if you are actually eligible: To claim the free offer you need to be a new Azure customer, so that means your account has never had a previous trial or been a paying Azure customer.

Most example ARM templates use a single JSON file to contain all of the deployment details in a single file. This works fine for smaller deployments, but once you start doing larger deployments, working in teams, or wanting to re-use parts of your deployment templates then you really need to start looking at nested templates. Nested templates describes the process of calling an ARM template from inside another. In this way you can separate your logic into multiple files, call these files as required and pass parameters and results between templates.

Back in June Microsoft introduced the ability to have an ARM template deploy to more than one resource group, at Ignite this year they went a step further to allow cross subscription deployments. It is now possible to have a single deployment create resources in multiple resource groups, regions and subscriptions, which is really useful if you are trying to deploy environments that include separate DR locations, or deployments that impact both a client and a core set of infrastructure.

As expected, day 1 of Microsoft’s Ignite conference saw a large number of announcements across all products, including Azure. Below you’ll find my summary of Azure announcements I pulled in from the conference floor. There are a lot of quality of life announcements that didn’t necessarily make it into the Keynotes, but that could be a big deal if they impact you. Also a quick reminder, if your at Ignite and have the time please feel to come see my sessions on Wednesday afternoon in community theatre 5, starting at 15.

It didn’t make it into todays Ignite Keynote, but today Microsoft released a preview of a new Azure service, Service Endpoints. It is now possible to take Azure services that have previously only had public endpoints, and restrict these to only allow access from a specific virtual network (or multiple networks), or even specific subnets. This preview is starting out with Azure SQL and Storage, with more services to come along soon.

Virtual Machines in a Scale Set provide a great way to spin up many identical machines in parralell. Thes VMs are all based on a common VM image and so unless all you need on your VMs is Windows, you are going to need to load applicaitons and data into these VMs. Getting your applications into that image can be done one of two ways: Use a Gallery image for your scale set and apply your applications on each VM when it is deployed using something like the PowerShell DSC extension, or Chef/Puppet etc.

In an on premises world, with Active Directory, password expiry is easy. Set the required policy for your domain, make sure it’s applied and forget about it, AD will take care of enforcing password changes and compliance with your password rules. Moving your identity to Azure complicates things, and that’s what we are going to talk about today, and in particular password expiry and related processes in the world of Azure AD Connect.

A while back I wrote an article talking about the new “Condition” option in Azure Resource Manger (ARM) templates. This was the first step into conditional logic in ARM templates and worked great where you needed to apply a condition at the resource level. Where it fell down was where you needed a condition inside a resource, this resulted in you having to duplicate objects with different settings and work around issues like duplicate naming.