LCM meta.mof not applying during push deployment


I’m pulling my hair out over this one, I think the problem is something to do with the WMF version.

My issue is that Azure DSC extension and Start-DscConfiguration are ignoring the LCM meta.mof configuration file. This means that instead of auto-rebooting and getting on with my configurations, the LCM just sits waiting for a manual reboot. My LCM configuration isn’t anything fancy:

  node localhost {

        LocalConfigurationManager {

            RebootNodeIfNeeded   = $true
            ActionAfterReboot    = 'ContinueConfiguration'
            AllowModuleOverwrite = $true

On my VM with WMF 5.0.10514.6 ($PSVersionTable) the LCM is applied, I see this in Get-DscConfiguration. On my other VM / Azure VM, version 5.0.10586.117, the meta.mof is ignored, Get-DscConfiguration shows default settings. I have checked and the meta.mof files are identical, in name and content. I even tried copying over the files from the server which successfully applied them to the non functional server and still the LCM configuration is ignored (I assume ignored as Get-DscLocalConfigiration is still showing standard settings).

Anyone else had the issue? I’m just reverting my snapshot on the machine running the old version, will update and retest to be sure that is the problem.



Right, the reason it works in one of my local test VM’s is that I had actually already configured the LCM previously, hence the settings were right. If I apply the meta.mof to set RebootNodeIfNeeded and ActionAfterReboot = $true and the run my scripts using Start-DSCOnfiguration, they work without any issues in my local Hyper-V machines.

Looking at Azure, the experience is the polar opposite. Its gets to various different points in the scripts and sits pending reboot. Looks like for some reason the DSC extension isn’t rebooting and I can’t force the LCM to update in the ARM template. The templates work, I just have to manually reboot enough time for it to complete.

Anyone experienced this? I’m using the latest schema and extension version.

      "name": "[concat(parameters('machineName'), '/',  variables('extensionPrefix'), 'dsc')]",
      "type": "Microsoft.Compute/virtualMachines/extensions",
      "location": "[parameters('location')]",
      "apiVersion": "2015-06-15",
      "dependsOn": [ ],
      "properties": {
        "publisher": "Microsoft.Powershell",
        "type": "DSC",
        "typeHandlerVersion": "2.19",
        "autoUpgradeMinorVersion": true,
        "settings": {
          "wmfVersion": "latest",
          "configuration": {
            "url": "[variables('templateUri')]",
            "script": "[parameters('dscConfigurationScript')]",
            "function": "[parameters('dscConfigurationFunction')]"
          "configurationArguments": {
            "DomainName": "[parameters('domainName')]",
            "gui": "[parameters('gui')]",
            "timeZone": "[parameters('timeZone')]",
            "siteName": "[parameters('siteName')]"
          "configurationData": {
            "url": "[variables('parameterUri')]"
          "privacy": {
            "dataCollection": "enable"
          "advancedOptions": {
            "forcePullAndApply": false
        "protectedSettings": {
          "configurationArguments": {
            "AdminCred": {
              "UserName": "[parameters('domainUsername')]",
              "Password": "[parameters('domainPassword')]"
            "sCred": {
              "userName": "[parameters('domainUsername')]",
              "password": "[parameters('safeModePassword')]"
          "configurationUrlSasToken": "[parameters('_artifactsLocationSasToken')]"

After you hit this failure, can you capture diagnostics zip using these instructions
xDscDiagnostic Gather Diagnostics Zip

Twitter info is on my profile if you want to arrange to send it to me directly.


Did you realize you are trying to configure a LCM with the PS 4.0 procedure?

Have you tried the new format?

Good afternoon,

Thanks for you input on this, I had seen the responses earlier in the week but hadn’t have a chance to test and reply until today. I have now found a way to work around the issue, it doesn’t resolve the underlying issue but lets me move forward.

The issue is with the Azure DSC extension, it looks as if it should be acting on behalf of the LCM when executing. On a machine which executes the code correctly, the DSC extension uses RebootNodeIfNeeded : True. E.g.

VERBOSE: [2016-07-10T11:40:18] Sequence Number : 0
VERBOSE: [2016-07-10T11:40:18] Previous Sequence : 0
VERBOSE: [2016-07-10T11:40:18] RebootPending : False
VERBOSE: [2016-07-10T11:40:18] RebootNodeIfNeeded : True
VERBOSE: [2016-07-10T11:40:18] UseExisting : False
VERBOSE: [2016-07-10T11:40:18] State : Completed

On a machine which fails to execute correctly, RebootIfNeeded is not set:

VERBOSE: [2016-07-10T13:00:15] Sequence Number : 1
VERBOSE: [2016-07-10T13:00:15] Previous Sequence : 1
VERBOSE: [2016-07-10T13:00:15] RebootPending : False
VERBOSE: [2016-07-10T13:00:15] RebootNodeIfNeeded : False
VERBOSE: [2016-07-10T13:00:15] UseExisting : False
VERBOSE: [2016-07-10T13:00:15] State : Completed

Now why it is not setting this value is a mystery at the moment, its exactly the same Azure ARM json template which executes the DSC configurations. The template is based on the latest schema:

The configuration is different, the one that works is NewForest whereas the ones which fail are promotedc and promoterodc, but the basis of the configuration is the same.

I have worked around the problem by setting the LCM using the WMF 5 method suggested by Kyle. The way I do this is within the ARM template. The methodology is as follows:

  1. Build VM.
  2. Add a DSC extension, send a configuration script to set the LCM.
  3. Update the DSC extension, sending it the DSC configuration for the server.

By doing this, the LCM takes over from the ARM DSC extension, forces the reboot, and the machine acts as it would on premise.
There is an issue with doing this however, because the LCM is taking over, the Azure end thinks the configuration has completed successfully when it has not. This means the Azure side will enact any further steps within the template before the extension has finished. For my purposes right now, this isn’t an issue as the application configuration comes last, but it might hurt me later on with more complex configurations.

Is there a way to combine the LCM configuration inside of an existing template? I tried a composite nested within the script but it didn’t seem to work, this put everything in the script into a meta.mof rather then creating separate MOFs.

I’ll keep digging into why its not working.They’ll probably update the extension in a few weeks and it will work without issue.

Thanks for your help, if anyone else has any suggestions or knows why this issue might be occurring I’d be keen to hear the information.