NOTE: For information on OS support, and other features, please refer to our release history.
Today we are releasing version 2.0 of the Azure DSC Extension, with improvements for DSC configurations that reboot the VM, and fixes for ARM deployments.
We are releasing this version as a major version change, instead of a minor revision, because you may need to modify your DSC configuration in order to use this release. The change in this release might affect you if
- your DSC configuration reboots the VM
- or you are using the DSC Extension within an ARM template and need to apply the same template to the same VM multiple times
- or you are using the Set-AzureVMExtension cmdlet instead of Set-AzureVMDscExtension
Otherwise, the Extension should have the same behavior as in previous versions and you should have no problem continuing to use the same DSC configuration.
The changes you need to make are covered below.
Installing Version 2.0
The default version for the Set-AzureVMDSCExtension cmdlet will continue to be “1.*” for a couple of releases of the Azure SDK; in the meanwhile, you will need to specify the version explicitly in order to install 2.0:
PS> Set-AzureVMDscExtension -Version 2.0 …
You can also use “–Version 2.*” if you would like your VM to auto-update when we release subsequent versions. Please note these updates might cause your VM to reboot if a newer version of the Extension uses a newer version of the WMF.
In an ARM template you would specify the version as usual:
001 002 003 004 005 006 | "properties": { "publisher": "Microsoft.Powershell", "type": "DSC", "typeHandlerVersion": "2.0", … } |
and use the autoUpgradeMinorVersion flag if you want auto-updates:
001 002 003 004 005 006 007 | "properties": { "publisher": "Microsoft.Powershell", "type": "DSC", "typeHandlerVersion": "2.0", "autoUpgradeMinorVersion": “true” … } |
Reboot scenarios
There are 2 flags that control when DSC reboots a machine: a DSC resource can request DSC to reboot by setting $global:DSCMachineStatus = 1; the Local Configuration Manager will then reboot the machine only if the metaconfiguration in the DSC configuration specifies RebootNodeIfNeeded = $true:
001 002 003 004 005 006 007 008 009 | configuration … { … LocalConfigurationManager { RebootNodeIfNeeded = $true … } } |
Versions 1.0-1.10 of the DSC extension ignore the RebootNodeIfNeeded flag and always reboot the VM if a resource requests it. This has two issues: for one thing, the extension will reboot the VM even if the configuration explicitly sets RebootNodeIfNeeded to $false. Secondly, when the flag is true the extension may fail (depending on timing) because the OS may receive 2 simultaneous reboot requests (one initiated by the LCM, and the other by the Extension).
As a workaround for the second issue, we have been asking users of the DSC Extension to remove RebootNodeIfNeeded from their configurations. In Version 2.0, this workaround is no longer needed: the Extension will look at the value of RebootNodeIfNeeded and take over the responsibility of rebooting the VM. The Extension will now reboot the VM if a resource requests it, and RebootNodeIfNeeded is set to true.
If you removed RebootNodeIfNeeded from your configuration to workaround the above issue in versions 1.1-1.10, you will need to add it back to your configuration or the Extension V2.0 will not reboot the VM.
Handling repeated calls to the DSC Extension by the Azure VM Agent
During ARM deployments (or in Azure Service Management, when multiple VMs are hosted within the same cloud service) the Azure VM Agent may invoke the DSC Extension multiple times with the same parameters. The DSC Extension will then process the first invocation and, if it is invoked again while it is executing the first configuration, it will fail the additional invocations. This behavior produces intermittent errors during ARM deployments, most of the time manifested by the error message
“File lock (C:\Packages\Plugins\Microsoft.Powershell.DSC\1.10.1.0\bin\..\DSCWork\ExtensionHandler.Lock.dsc) exists: another instance of the extension is already running."
In Version 2.0, the DSC Extension will simply ignore these extra invocations and the above error will not occur. This change of behavior may affect you if you execute the DSC Extension with the same parameters on the same VM multiple times, for example if you re-apply the same ARM template. If you execute the Extension only 1 time on each VM, or use different values each time, then this change will not affect you.
Keep the following in mind when using Version 2.0:
- If you are using the extension via the Set-AzureVMDscExtension cmdlet, you don’t need to do anything special. This cmdlet adds a unique token to each invocation of the Extension.
- If you are using the extension via the Set-AzureVMExtension cmdlet, you need to add the –ForceUpdate parameter:
PS> Set-AzureVMExtension –ForceUpdate …
- Unfortunately, ARM does not have an equivalent to –ForceUpdate (it will be added in the near future) so if you re-apply the same template to a VM, you need to ensure at least one parameter has a different value than the previous invocations. One way to accomplish this is to add a dummy optional argument to your DSC configuration and then pass a unique value each time you apply your template to the same VM.
Reporting status to the Azure VM Agent
Another small change in Version 2.0 is that the DSC Extension no longer reports the ‘warning’ status to the Azure VM Agent. Previous versions would report ‘warning’ if the DSC configuration produced any warnings, but this status is not considered a terminal state and ARM deployments would timeout when it was reported.
The status can be queried with Get-AzureVMDscExtensionStatus:
PS> Get-AzureVMDscExtensionStatus na-2008r2-0
ServiceName : na-2008r2-0
Name : NA-2008R2-0
Status : Success
StatusCode : 1
Timestamp : 6/16/2015 3:59:31 PM
StatusMessage : DSC configuration was applied successfully.
DscConfigurationLog : {Perform operation 'Invoke CimMethod' with following parameters, ''methodName' =
SendConfigurationApply,'className' = MSFT_DSCLocalConfigurationManager,'namespaceName' =
root/Microsoft/Windows/DesiredStateConfiguration'., An LCM method call arrived from computer
NA-2008R2-0 with user sid S-1-5-18., [NA-2008R2-0]: LCM: [ Start Set ], [NA-2008R2-0]:
LCM: [ Start Resource ] [[Script]dummyscript]...}
PS> Starting in Version 2.0, the only possible status are ‘transitioning’, ‘error’ and ‘success’ (‘transitioning’ indicates that the extension is still executing the configuration).
Warnings are still reported within the ‘DscConfigurationLog’ property in the output of Get-AzureVMDscExtensionStatus.
Feedback
As always, your feedback is important. Please feel free to reach to us posting comments to this post, or using Connect: https://connect.microsoft.com/PowerShell/Feedback.