What I Learned From the Microsoft DSC Team at the PowerShell Summit

If you have been following my blog at all, you know that I have been using this article to do some testing with Virtual Machine Manager using injected DSC Configurations.  You will also know that I have had quite some difficulty getting things to work, and I couldn’t really come up with any explanations why.  I was able to spend some time at the PowerShell Summit this week speaking with members of the DSC team, and found out quite a few things which I have outlined below.

  • If you inject a simple Configuration that does things that require no reboots and it works, everything will work fine
  • If your Configuration, at any point during the first time it runs, fails, you are screwed.  The pending.mof file gets deleted, and nothing you do can get DSC to recognize it again.  This was the big issue I ran into, and it turns out that it is a bug.  They know about it and are working on it.
  • Similar to those lines, if your Configuration requires a reboot, you are also screwed.  While that article explicitly says that “feel free to replace this configuration with your own. The xComputer page has more samples for common tasks including renaming your computer, joining a domain, etc.” don’t do that.  Most of those tasks require a reboot.  What will happen is your Configuration will run, and in my case I was trying to rename the computer, then join the domain.  The computer rename requires a restart.  After it renames the computer, it just sits there and does nothing (remember, it’s running as a scheduled task in the background), waiting for a reboot.  If you forcefully restart the computer, the Configuration fails and you are screwed again.  I wonder if you set the Local Configuration Manager to apply and autocorrect, and to restart when needed if it would get past this issue.  I haven’t tried this yet, but will be doing so this week (maybe even today!)
  • Obviously, you can get around all of these issues just by using a Pull server and having your injected DSC Configuration configure the LCM and then pull it’s Configuration from the Pull Server.  This will allow it to reboot whenever, and then pull the Configuration again and again until everything is set the way it is supposed to be.
  • In the Scheduled Task the .CMD file is creating, there is this line:  Arg @{Flags = [System.UInt32]3 }'” .  There are 3 possible values for the end of that line.  The 3 tells the scheduled task that it is a bootstrap operation.  Following up on above, once the pending.mof fails, something with DSC changes this value to a 2.  You cannot change it back to a 3.  It will let you change it, but as soon as you say Apply and OK, if you go back and look at it it’s a 2 again.  I even deleted this task entirely and recreated it using the .CMD, and I still couldn’t get it to take anything but a value of 2.  In talking with the team this is evidently how it’s supposed to work.  The 2 refers to the DSCRestartBoot Task, and the 1 refers to the Consistency check Scheduled Task.
  • Not related to the rest of this, but I was also told (not by a member of the DSC team) that if you set the IP Address, Gateway, Subnet etc using DSC, and then remove just the Gateway, that when Configuration runs again, it won’t change the Gateway back to what it’s supposed to be.  I haven’t tested this myself, but I have no reason to believe they were making this up.