Azure-Resource-Manager

Using Linked Templates and Conditional Logic in ARM

Using Linked Templates and Conditional Logic in ARM

Microsoft have now added first class conditions to the language so this workaround is no longer required. See this article on how to use this feature.** ARM Templates are a great tool for deploying complex sets of resources in Azure, however as it currently stands there is no concept of an “If” statement in a template. This can make it much more difficult to support the re-use of code and to avoid duplication in your templates, if you have to create a whole new set of templates which are 95% the same but with one section being different.
Protecting Azure Resources with Resource Manager Locks

Protecting Azure Resources with Resource Manager Locks

Resource Manager Locks provide a way for administrators to lock down Azure resources to prevent deletion or changing of a resource. These locks sit outside of the Role Based Access Controls (RBAC) hierarchy and when applied will place the restriction on the resource for all users. These are very useful when you have an important resource in your subscription which users should not be able to delete or change and can help prevent accidental and malicious changes or deletion.
Azure Resource Manager Resources

Azure Resource Manager Resources

Azure Resource Manager (ARM), the new V2 method for deploying Azure resources offers a new template based deployment method. Using JSON based templates it is quick and easy to build a repeatable deployment process. If you are just starting out with this new process then the resources below may help with your transition. Azure Resource Manager Quick Start Templates https://github.com/Azure/azure-quickstart-templates Microsoft has produced a huge range of pre-built templates using ARM that you can either deploy straight to Azure from the Github repository, or download and use as the basis for your own templates.
Azure Resource Manager and Multiple NAT Rules

Azure Resource Manager and Multiple NAT Rules

Back in the days of cloud services every VM created got a set of default endpoints that let in traffic for RDP and Remoting on a random port, and if you wanted ingress on other ports you just created more endpoints. In the V2 world cloud services don’t exist, and endpoints are now primary configured as inbound NAT rules on a load balancer, with the default being no NAT rules. This is ultimately a much better and more secure way of doing it, however it did make it a pain when you needed to add one or more NAT rule for each VM in your deployment, especially when you had lots of VM’s.
Outbound IP and Azure Resource Manager

Outbound IP and Azure Resource Manager

It’s often necessary to configure Azure virtual machines to use a consistent outbound IP address, to connect to another resource with an IP based whitelist. In a classic cloud service based deployment this was easy, all of the VM’s in the cloud service used the cloud services IP for outbound traffic and all was well. In an Azure Resource Manager (ARM) deployment things are different. There’s no concept of cloud services and public IP’s are assigned to VM’s or load balencers.