Desired state configuration is exactly what it sounds like and addresses the ongoing problem of configuration drift in Windows and Linux operating systems on physical and virtual machines. DSC is designed to assist in solving administration issues like:

• Are all machines conforming to their intended configuration as when they were originally deployed?
• How can unintended changes to a machine's configuration by people and applications be prevented?
• How can new machines be deployed with the same configuration as those performing the same role?
• How can access permission to change a machine's configuration be enforced and managed?
• How can a machine's or group of machines' configurations be updated with minimal downtime?

This nirvana of configuration stability can be achieved with Azure Automation Desired State Configuration. Automation DSC will allow you to deploy, maintain and monitor infrastructure resources from the cloud, even across hybrid environments, making sure that physical and virtual machines conform to intended and pre-defined configurations.

Essentially Azure Automation State Configuration takes PowerShell Desired State Configuration functionality and wraps it in a user friendlier experience allowing you to create, manage, apply, and report on DSC resources and their implemented configurations. The DSC resources are stored on an Automation DSC server where machines can pull the desired state configurations and apply them, ensuring they are in a conforming state, reporting back their compliance or lack of.

Azure allows you to access resources' compliance to predefined policies and quickly identify those that are non-compliant. The assessment is performed by comparing a resource's properties with a known policy definition defined in a JSON template. This is an extension of the ARM template paradigm, which makes sense – no need to reinvent the wheel. Like all resources, policies can be assigned in a multitude of ways, through the portal, with PowerShell or Azure CLI. Here we are assigning a predefined policy through the portal to identify Azure VMs that don't use managed disks.

If we look at the policy detail, we can see the JSON definition, shown here on the left, where the policy definition id is the third line from the bottom. On the right is an ARM template for deploying the policy with the policy assignment name parameter default value made up from the policy definition id and resource group.

No matter the OS, a single instance of a VM is guaranteed up-time and connectivity of 99.9%. If you deploy two or more instances of a VM within a data center in an Availability Set, you are guaranteed 99.95% up-time. When the instances are deployed across multiple data centers in an Availability Zone configuration, at least 99.99% connectivity is guaranteed. At 99.99%, you can still potentially face over 52 minutes a year of interrupted service. A minute a week during off-peak hours might be OK if there were no follow-on consequences, but 26 minutes twice a year during crucial peak load periods is unsatisfactory. To take advantage of Azures' single instance SLA, all disks attached to a VM must be either Premium or Ultra SSDs.

When it comes to the database setup, the system's heart, it is recommended to deploy a hot standby backup database server. At a minimum, this should be two VMs in an Availability Set at another data center in the same region with database replication from the primary servers. The assumption being the primary servers are also in an Availability Set configuration. The backup servers are deployed in the same virtual network. Depending on the DBMS, replication can be facilitated via HANA System Replication, Oracle Data Guard, or SQL Server Always On technologies. For added peace of mind, in the unlikely but possible case of a complete Azure region outage, you can deploy an asynchronously replicating database VM in another Azure region.