Configuring Virtual Machines using Azure Automation DSC

A few days ago, I published an article on how to apply a DSC configuration on an Azure Virtual machine. Although there's nothing wrong with publishing a configuration on an Azure Storage Account and having the machines apply it, there's a better way.

Azure offers a service called Automation Accounts, that among  other things, let's you publish configurations, register nodes in order to apply them and report on the node status. Let's see how to get it working!

We are going to need and Azure Automation Account to host the configurations, so let's create one:

PS C:\> New-AzureRmAutomationAccount -ResourceGroupName "Blog-DSC" `
                                     -Name "BlogDSCAutomationAccount" `
                                     -Plan Free `
                                     -Location WestEurope

SubscriptionId        : e******a-8**c-4**3-9**7-b**********9
ResourceGroupName     : Blog-DSC
AutomationAccountName : BlogDSCAutomationAccount
Location              : WestEurope
State                 : Ok
Plan                  : Basic
Tags                  : {}

PS C:\>

Now that we have the account, we can upload the configuration file. I've run into issues when trying to upload using the relative path of the file, so please keep it in mind.

PS C:\> Import-AzureRmAutomationDscConfiguration -SourcePath C:\Users\admin\Desktop\TestConfig.ps1 `
                                                 -Description "Test Configuration" `
                                                 -ResourceGroupName Blog-DSC `
                                                 -AutomationAccountName "BlogDSCAutomationAccount" `
                                                 -Published:$true `
                                                 -Force

ResourceGroupName     : Blog-DSC
AutomationAccountName : BlogDSCAutomationAccount
Location              : WestEurope
State                 : Published
Name                  : TestConfig
Tags                  : {}
Description           : Test Configuration
Parameters            : {}
LogVerbose            : False

PS C:\>

The next step after publishing the configuration is to compile it. A compilation task is started with the Start-AzureRmAutomationDscCompilationJob cmdlet:

PS C:\> Start-AzureRmAutomationDscCompilationJob -ResourceGroupName "Blog-DSC" `
                                                 -AutomationAccountName "BlogDSCAutomationAccount" `
                                                 -ConfigurationName "TestConfig"

ResourceGroupName      : Blog-DSC
AutomationAccountName  : BlogDSCAutomationAccount
Id                     : 3******7-0**9-4**a-a**6-4***********1
Status                 : New
StatusDetails          : None
StartTime              :
EndTime                :
Exception              :
JobParameters          : {}
ConfigurationName      : TestConfig

PS C:\>

Give it some time and check the status of the task using the Get-AzureRmAutomationDscCompilationJob cmdlet:

PS C:\> Get-AzureRmAutomationDscCompilationJob -ResourceGroupName "Blog-DSC" `
                                               -AutomationAccountName "BlogDSCAutomationAccount" `
                                               -ConfigurationName "TestConfig"

ResourceGroupName      : Blog-DSC
AutomationAccountName  : BlogDSCAutomationAccount
Id                     : 3******7-0**9-4**a-a************1
Status                 : Completed
StatusDetails          :
Exception              :
JobParameters          : {}
ConfigurationName      : TestConfig

PS C:\>

The compilation task has completed, we're ready to register some nodes!

Existing machines can be registered using the Register-AzureRmAutomationDscNode cmdlet:

PS C:\> Register-AzureRmAutomationDscNode -AzureVMName "DSC-Test-002" `
                                          -NodeConfigurationName "TestConfig" `
                                          -ConfigurationMode ApplyAndAutocorrect `
                                          -AzureVMResourceGroup "TestDSC2" `
                                          -AutomationAccountName "BlogDSCAutomationAccount" `
                                          -ResourceGroupName "Blog-DSC"

PS C:\>

To automatically register machines upon their creation, you can update their ARM template to include the DSC extension. You may find more information on the extension template here. You're going to need some information for the registration, you can get it using the below command:

PS C:\> Get-AzureRmAutomationAccount -Name "BlogDSCAutomationAccount" -ResourceGroupName "Blog-DSC" | Get-AzureRmAutomationRegistrationInfo

ResourceGroupName : Blog-DSC
AutomationAccountName : BlogDSCAutomationAccount
PrimaryKey : erA5niqoR3rfHWIArGK7rwNOmtpexdg******************==
SecondaryKey : 5T4ScJtDKko95LMac/vlLVJ6IBWPY6w****************==
Endpoint : https://we-agentservice-prod-1.azure-automation.net/accounts/**********

PS C:\>

Have fun!

Popular posts from this blog

Domain Controller Machine Password Reset

Image
On my lab environment, I've configured two Active Directory sites since most enterprises have offices in more that one places. My lab however is not running 24/7 and the domain controllers in the second site are rarely turned on in order to save resources. This leads to issues with the Active Directory replication such as the "The target principal name is incorrect" error when I execute:  repadmin /syncall /AdeP. To remedy the issue, we have to reset the machine password of the domain controller that has been offline. First off, we are going to stop and disable the Kerberos Key Distribution Center (kdc) service on the problematic domain controller, in our case DC4. There may be some tickets in the cache so we should also clear them using klist purge Now it's time to change the machine password of the domain controller using the command netdom resetpwd /s:dc3 /ud:lab\administrator /pd:* Replace the "lab\administrator" with an account on your
Keep reading

Configuring a Certificate on Exchange Receive Connector

Today's article is about configuring Exchange receive connectors with specific certificates. Out of the box, Exchange uses self signed certificates to provide TLS secured mail flow. This will definitely be an issue if you expose the SMTP protocol to client computers since they won't trust the certificate. In this article we are going to configure a certificate that was issued by a third part authority to the Client Frontend receive connector. We'll start with getting the thumbprint of the certificate using the Get-ExchangeCertificate cmdlet: [PS] C:\> Get-ExchangeCertificate Thumbprint                               Subject ----------                               ------- 241B864DC82C664FECBA18B8D54987AAFB65B4C2 CN=*.lab.com, ... D4D210886B34E690191A1F008C78FDD0E7325DD4 CN=Exchange2013A 960171662EB261162F9C8CBE12E0B75D6F06ABB0 CN=Microsoft Exchange Server Auth Certificate 2690324B827A9F2B75D59104F81CAAA57CDD627B CN=WMSvc-Exchange2013A [PS]
Keep reading

Managing Active Directory User Certificates using PowerShell

I first came across user certificates when I was working with email certificates a few years ago and I have to admit that I had trouble updating the certificates on the objects! Most organizations have a Microsoft Active Directory Certification Authority that issues the certificates used internally. When a certificate is issued to a user, the Microsoft Certificate Service saves the public key in Active Directory. The userCertificate attribute is a multi-valued attribute that contains the DER-encoded X509v3 certificates issued to the user. Although we rarely need to pay attention to this attribute, there are cases where we have to update it. To make things easier, I've written PowerShell functions to Get, Remove, Import and Export the certificates on that field. To get the list of certificates for an object, use the Get-ActiveDirectoryObjectCertificate function: PS C:\> Get-ActiveDirectoryObjectCertificate -UserPrincipalName cpolydorou@lab.local DistinguishedName     
Keep reading