Adding and using the DSC For Linux extension v2 to Azure Stack TP2

In the previous post we added the CentOS 7.2 OS Gallery Item and Linux diagnostic VM Extension to the stack.

Because you have already seen the process of adding a VM Extension to Azure Stack, this blog post will focus more on the using aspect of the DSC For Linux VM extension to set the ground for blog posts to come.

In this series:

Adding and using….

VM Extensions shipped with TP2

Let’s enumerate the VM extension shipped with TP2 by running this script (I assume you already setup the Azure Stack connection in PowerShell).


We can see that quit a few VM Extensions are already present plus the Linux Diagnostics one we imported in the previous blog. As you probably already notices, the DSC For Linux extension did not ship with Azure Stack so we need to bring it in ourselves.

Adding the DSC For Linux VM Extension

Again I’ve gone ahead and deployed a VM in public Azure and copied the VM Extension from there to my GitHub account. You can download it here: The Linux VM extensions are openly being develop on GitHub if you’re interested.

After you have downloaded it, we need to place it on the host in the C:\ClusterStorage\Volume1\Shares\SU1_Infrastructure_1\CRP\GuestArtifactRepository directory.

Let’s create a new folder here called: DSCForLinux and copy in the zip file we just downloaded.

Now we need to add a manifest file so this VM extension will be available. Create a file called manifest.json and copy in the following:


You can validate if you have added it correctly by running:

If you get output instead of an exception, you’re good to go!


Using the DSC For Linux VM Extension

From the GitHub repository where the DSC For Linux VM Extension is being developed, we can see what the VM Extension expects as inputs to operate.


Basically the “Mode” used, dictates what other parameters are required. E.g. Push / Pull mode requires the FileUri to point to a mof (Push) or meta.mof (Pull) file and if your file is on a storage account which is not set to Blob sharing, you can additionally specify the StorageAccountName and Key.

We’ll look at two functionalities of the VM Extension:

  • Push (converge from pre-compiled mof)
  • Register (onboard into Automation DSC service)

Setting up prerequisites

Because we take some dependencies on external resources, we need to set those up first.

Compiling a mof and making it available

We need to pre-compile a mof file which we will Push to the node. We need to pre-compile a mof because unlike the DSC For Windows VM Extension, the DSC For Linux VM extension cannot consume a configuration script to compile it on the VM.

First let’s install the NX PowerShell module so we have the correct schema files to create a mof for a Linux system from a Windows system.

If this is the first time you use PowerShellGet, you will get prompted to download and install the requirements for this to work.

Now we can write and compile the mof file. Let’s look at the configuration script:

This configuration will make sure NGINX (among other things, a light weight web server) is installed. Because the default CentOS package repository doesn’t contain the packages needed, the epel-release package will be installed, allowing to get and install packages from the epel repository.

When NGINX is installed, the default website is modified and the NGINX daemon is started.

Please note that this configuration is not compatible with debian based distributions (e.g. Ubuntu) as these use, among other things, different package managers.

Now let’s compile this mof and put it on the storage account.

First run the configuration script, making the configuration available in memory. Then:

Which will compile the localhost.mof file located at c:\NGINX

Next, we upload the localhost.mof file to the storage account:

Make a note of the Uri as we need it later on.

Setting up an Automation Account

I’m assuming you will have an Azure subscription and your Azure Stack VMs are capable of communicating with the internet. We are utilizing a hybrid scenario here where Azure Stack VMs get onboarded into Automation DSC.

If you don’t already have an Automation Account, go and set one up. If you need to know more about Azure Automation, go to the Azure documentation about it here:

Now you have your Automation Account. We need the Uri and one of the 2 access keys associated with it.


Make a note of these as we need those later on.

Deploy using PowerShell

In this scenario we will deploy a CentOS VM using AzureRm PowerShell cmdlets. The DSC For Linux extension will download the mof file we published on the storage account. As the container has the Blob permission set, we won’t have to specify the storage account name nor key (public Uri).


Now the VM is deployed and the DSC For Linux VM Extension was added to it. Let’s check if the mof file was applied. I opened port 80 so we can just connect to the public IP and see if we get a result.


Success, we can also see some status information using:


Deploy using ARM template

In this scenario we will deploy a CentOS VM using a JSON template. The DSC For Linux extension will register the node to Azure Automation DSC so we need to provide the Automation Uri and one of the access keys. The deployment will be triggered by PowerShell.

Save the following as Deploy.json:

You could also paste it in the Template Deployment widget, but in this case we will deploy the template using PowerShell.


Let’s look in the Azure Automation Account if things worked as expected:


Deploy using Portal

So now we want to use this VM extension from the Portal. If you browse the Portal and look for the extension, it is simply not there.


The extension is not provided through the Portal in Public Azure so there are no artifacts created by Microsfot yet.

As with OS Gallery Items, we need to create VM Extension Gallery Items to light them up in the Portal. That will be the topic of the next couple of blogs so stay tuned!

Spread the word. Share this post!

Ben Gelens

About the author

Ben Gelens is a PowerShell MVP and technical consultant at Inovativ in the Netherlands where he works as a member of the CloudOS team. While building clouds for his customers, Ben’s primary focus is automation and orchestration. As such, Ben has a great deal of field experience on all kinds of PowerShell subjects (e.g. Remoting, Tool making, DSC, SMA, Workflow) in all kinds of areas (e.g. Windows Azure Pack, Active Directory, Office 365, Server Management, Azure). Ben is an active IT community participant and speaker. He is a member of the community, a member of the Dutch PowerShell User Group and a contributing author for PowerShell magazine.

Twitter: @bgelens