Azure : Deploying a domain controller via DSC pull


Today’s blog post will showcase how you can leverage the DSC pull feature of Azure Automation when deploying workloads to Azure. To many, the following question will pop up ; “Why use a pull mechanism, whilst I could use the DSC extension to push my configs?”. The answer is pretty simple  The pull mechanism facilitates the lifecycle flow of workloads better. You can easily update the config of the virtual machine and do follow-up on the rollout of your configuration.


The Flow

Now how would such a flow go?

  1. We’ll use an ARM template to deploy (and afterwards keep) our Azure Automation Account (up-to-date)
  2. We’ll use a script to import the Powershell modules into our Azure Automation Account, which are needed to compile configurations.
  3. We’ll use a script to import & compile the DSC configurations into ou Azure Automation Account.
  4. We’ll use an ARM template to deploy the domain controller.
  5. This ARM template will also register the VM with the Azure Automation Account and link it with a given DSC configuration.
  6. The configuration will be applied and the updates will be reported back to the Azure Automation Account.


Deep-dive Demo

(EDIT 30/7/17  : Added network pre-req)

Continue reading “Azure : Deploying a domain controller via DSC pull”

Domain Join : ARM Extension versus Azure Automation DSC


So you’ve already deployed Windows based systems in Azure. Very good! You’ve probably joined those systems into a domain, as you’ve always done this by going through the GUI. Did you know you can join a machine without logging into the machine? No? Then today’s post will be very interesting for you!

If you knew this was possible, then I’ll show you that there are various methods of doing so. And that each approach will have clear advantages and even disadvantages. So let’s get ready to domainjoin those systems!


Continue reading “Domain Join : ARM Extension versus Azure Automation DSC”

Enforcing your DSC config on Linux


In the previous post we talked about configuring a Linux host with DSC via Azure Automation. When using the default settings, as we did in that post, a node configuration will be set to “apply & monitor”. Today we’ll take a look at how you can force compliancy with a certain config.

When we take a look at the, we notice that there is an option to change the “ConfigurationMode”.

root@docker02:/opt/microsoft/dsc# /opt/microsoft/dsc/Scripts/ --help
Usage: [OPTIONS]
OPTIONS (case insensitive):
--RegistrationKey KEY
--ServerURL URL
--ConfigurationName NAME
--RefreshFrequencyMins NUM default=30
--ConfigurationModeFrequencyMins NUM default=15
--ConfigurationMode (ApplyAndMonitor,ApplyAndAutoCorrect,ApplyOnly) default=ApplyAndMonitor
--RefreshMode (Pull|Push) default=Pull


The default

By default it is set to “ApplyAndMonitor”… So when I would manually mess with the system, by removing a required package. Then that node would become “Non Compliant”.


So our reporting will indicate that something is odd. But there will be no remediation.



By using the “ApplyAndAutoCorrect” option, we can ensure that DSC will take action when a system is non-compliant. To set this mode, use the following command ;

root@docker02:~# /opt/microsoft/dsc/Scripts/ --RegistrationKey my-secret-key --ServerURL --ConfigurationMode ApplyAndAutoCorrect


“The Test”

Let’s take a look what the node will do when we remove one of the packages that has been included in the node configuration. To speed up my process, I reduced the refresh frequencyso I don’t have to wait endlessly… 😉

–RefreshFrequencyMins 5
–ConfigurationModeFrequencyMins 5

Anyhow, all looks good!


So now let’s screw up this node…

root@docker02:/opt/microsoft/dsc# date && htop --help
Die Sep 20 20:16:38 CEST 2016
htop 2.0.1 - (C) 2004-2016 Hisham Muhammad
root@docker02:/opt/microsoft/dsc# date && apt-get remove htop -y
Die Sep 20 20:17:01 CEST 2016
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:

And the testing took a bit, longer as I noticed that the ConfigurationModeFrequencyMins option did not get set…

root@docker02:/opt/microsoft/dsc# Scripts/
instance of GetMetaConfiguration
MetaConfiguration= instance of MSFT_DSCMetaConfiguration


… *waiting* …

Wait for it… and it’s back!

root@docker02:/opt/microsoft/dsc# date && htop --help
Die Sep 20 20:45:30 CEST 2016
htop 2.0.1 - (C) 2004-2016 Hisham Muhammad
Released under the GNU GPL.




  • By default a non-compliant node will be reported, though no remediation will be done.
  • It is possible to configure the node to run in a mode where compliancy is enforced.

Managing Linux hosts with Desired State Configuration via Azure Automation


For this post I’ll be assuming you know the basics of Desired State Configuration (or DSC in short). The objective of today is to test what Azure Automation can bring to the table in terms of managing Linux hosts. We all know about Puppet, Chef, Ansible, … but is Azure Automation a viable alternative? 



First things first… Azure Automation Account

When getting started with DSC on linux, check out this documentation page as a reference. First up, we’ll create an Azure Automation account.


Copy one of the keys and the URL, as we’ll need it to manually register our “OnPremise” host.

Continue reading “Managing Linux hosts with Desired State Configuration via Azure Automation”