Azure : Deploying a domain controller via DSC pull

Introduction

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)

Domain Join : ARM Extension versus Azure Automation DSC

Introduction

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!

 

Enforcing your DSC config on Linux

Introduction

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.

 

Register.py

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

root@docker02:/opt/microsoft/dsc# /opt/microsoft/dsc/Scripts/Register.py --help
Usage: Register.py [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
--Help

 

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.

 

Enforce!

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/Register.py --RegistrationKey my-secret-key --ServerURL https://we-agentservice-prod-1.azure-automation.net/accounts/accountid --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:
htop
...

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

root@docker02:/opt/microsoft/dsc# Scripts/GetDscLocalConfigurationManager.py
instance of GetMetaConfiguration
{
ReturnValue=0
MetaConfiguration= instance of MSFT_DSCMetaConfiguration
{
ConfigurationModeFrequencyMins=30
RebootNodeIfNeeded=false
ConfigurationMode=ApplyAndAutoCorrect
Credential=NULL
RefreshMode=Pull
CertificateID=NULL
ConfigurationID=NULL
DownloadManagerName=NULL
DownloadManagerCustomData=NULL
RefreshFrequencyMins=1
AllowModuleOverwrite=false
LocalConfigurationManagerState=NULL
ConfigurationDownloadManagers=
{

 

… *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.
...

 

TL;DR

• 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

Introduction

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.