Domain Join using Azure Automation DSC

Now we have the ability to store DSC configurations in the cloud as part of an Azure Automation account. There are a few caveats to doing though – in this blog I will take you through joining a computer to a domain using Azure Automation DSC.

First things first I suggest you read https://azure.microsoft.com/en-us/documentation/articles/automation-dsc-overview/ and watch the video as it explains how the service works.

One of the items highlighted not in the actual blog but in the comments is that the configurations do not support PSCredential objects – as we have no way to secure them or use configuration data. So the resource needs to be modified to be able to accept string input else it will not work. Below are some of the steps I went through to get this to work.

As this feature is still in preview you need to run the below commands once you have connected to your Azure account to register for Azure Automation DSC

The commands for AA DSC are all part of Azure Resource Manager – so generally we are using that mode to run PowerShell against the service. We also need to use the preview portal in Azure to manage the features.

Ensure you have an automation account registered in the preview portal. You can create a new account by using the new account button in the portal or the command below:

Using Powershell below I do a couple of things. I create a new automation account and link it to my resource group (Line 3). Then I retrieve that account and store it in a variable (Line 5). Finally I run the Get-AzureAutomationRegistrationInfo cmdlet against my account and store the result in the $registrationinfo variable. I will use fields from this variable to register my node to AA DSC.

Copying directly from the link above we need to put settings for the Local Configuration Manager (LCM) into a JSON variable. We then pass this when the extension is installed. You can modify some of the variable to suit your needs if required.

Now we have enough information to register a node in AA DSC. I put the VM I want to register into a variable using Get-AzureVM – then use the Set-AzureVMExtension to add the DSC extension. After this you must update the VM to apply the configuration.

You just have to wait for the extension installation to complete – but when you check your automation account in the portal it will show the node as registered under the DSC Nodes blade. If there are issues you can check on the VM in C:\WindowsAzure\Logs\Plugins\Microsoft.Powershell.DSC\2.0.0.0 – there are log files which details what is happening as the extension is installed.

Now for modifying the resource – I am doing a domain join so I will use the xComputerManagement DSC resource and modify it. The original schema looks like below – it contains a couple of Credential objects.

As credentials object are not yet supported in AA DSC I need to modify the resource to accept string. First I go through all the folders and rename the ‘x’ prefix to ‘c’ to indicate I am changing the module. This has to be done everywhere including the schema mof file.

I then altered some of the properties inside the schema file to accept different values i.e. string for a password. Here is my new schema. As this was a quick play around I have forgone the unjoin credential and just added a password field. I also added a username value. In my DSC functions I will create a credential object using a combination of the domainname \ username.

I also modified the module file for the resource. I changed the parameters for each of the functions to match the schema: -

The original MOF file has a credential parameter – I added in some code to create a credential object using the value I supply in my $password parameter. This was added to each of the functions.

One last thing – at this time AA DSC doesn't support module versions – I need to rename the folder version number to cComputerManagement. My overall structure for the resource looks like below.

Once this has all been modified I can zip up the resource and load it into Azure Automation using the preview portal.

To ensure the module has loaded correctly I can use the Get-AzureAutomationModule cmdlet and check the status of my new module – it can take a few minutes before it is provisioned.

Now that this is complete I can write the DSC configuration for my server – as yet AA DSC doesn’t support configuration data so I have to accept any parameters into my configuration script and process them within. The node name I use does not have to reflect a server name – however it will appear as the configuration I supply to my node.

If your module is loaded correctly on your system you can use Ctrl-Space inside the resource to prompt you for the appropriate fields. I save my file and we are ready to compile it inside Azure. The Azure module contains cmdlets to process your configuration – these are done via compilation jobs. You supply the parameters for you configuration as a hash table to the compilation cmdlet.

The script below loads the configuration into Azure and then starts a compilation job with the parameters I supply.

The compilation job takes a few minutes to run – you can query the status by using the Get-AzureAutomationDSCCompilationJob cmdlet – if the jobs status returns as suspended you can supply the ID of the job to the above cmdlet and it will show you the errors genererated.

Once this is complete our configuration is ready to apply to the server using the cmdlets below. The cmdlet below will show me my configuration is available.

I can then apply it my server.

After the configuration has been applied and when the refresh frequency has been given time to apply the configuration your server will now be joined to domain. To force the configuration you can use the Update-DSCConfiguration cmdlet so it will contact the Azure DSC pull server.