PowerShell Desired State Configuration (DSC) Journey – Day 27

When we last left off, I was having some issues using injected DSC Configurations with Virtual Machine Manager.  After talking with the DSC Team at the PowerShell Summit I realized one major issue that I had was a bug.  To avoid unnecessary headache I am skipping ahead to step 2.2 of this document, which is without a doubt (in my mind anyways) the best way to do this anyways.

Here is what I have done since the last blog post, in order to make my life easier:

  • I have created a DSC Blank Template in VMM.  This template has only the OS installed (2012 R2) with the latest updates, and the WMF 5.0 Preview.
  • I built a new Pull Server for testing off of this template
  • I built a new VM off of my Blank Template, where I am going to be placing my injected Configuration and the .CMD, and saving it as a template.  I will then deploy my Test VMs off of this Template.  I am going to call this template DSCBase.

Also, I finally figured out why I was having such a problem with my injected DSC configurations from previous blog posts.  You can find that article here.  I am working with the DSC team so see what I can do about that, but really I probably just need to get with my network team and figure out a way to fix that from our side.

Since I don’t want to mess with setting an IP address for obvious reason, I am going to go with this Configuration to put on the template.

Alright, back to Step 2.2 “Inject a Meta-Configuration to Download a Document”. Deviating slightly from the instructions (I am instead going to follow the way the DSC E-Book does it), I am going to generate a new GUID for my Configuration, copy the localhost.mof to the Pull Server with the GUID attached, and create a new DSC Checksum for that file using the steps below.

And here are the files on my Pull Server:

The next step is to create a MetaConfiguration that will tell whatever VM is built off of the DSCBase Template to pull its Configuration from the server. Using the Script in the article, this is my Configuration (especially important to note that I replaced the ConfigurationID with the GUID I created).

I build the Configuration, and a localhost.meta.mof gets generated.

The article states that “Please note your metaconfig.mof should only contain MSFT_DSCMetaConfiguration and MSFT_KeyValuePair instances. You may need to manually remove OMI_ConfigurationDocument if it exists.”. I open up the localhost.meta.mof file and sure enough, I have that section in my file (show below) so I remove that section and save it.

Then I copy the localhost.meta.mof file to metaconfig.mof and manually copy it to my DSCBase Template VM under the %systemdrive%\Windows\System32\Configuration folder. I also opened up the metaconfig.mof and made sure it didn’t contain the OMI ConfigurationgDocument section (just because I am paranoid).

Here is what the %systemdrive%\Windows\System32\Configuration folder looks like on my DSCBase Template.

For the final two steps, I will attach the unattend.xml file to the Template when I create it. I copy the RunDSC.cmd file I had used previously to C:\DSC on the DSCBase Template VM. I don’t see anything that indicates this file should need to be changed from what I used when testing option 2.1 .

As a side note, I wanted to configure the Event Logs to enable the DSC Analytic and Debug logs but decided I was going to save that for either a Custom Resource or a customized Script Resource inside my Configuration.

Next step is to create the actual VMM Template from the VM itself. When that is done I will deploy a VM from this Template, and hopefully magic happens :).


Great success! The Scheduled Task was created,  and the screenshot below shows that the LCM is configured properly, with the correct Configuration ID.


I want to see if the new server has pulled it’s Configuration from the Pull Server, so I run the following commands on the Pull Server.

Looks like the last time anything ran on the Pull Server was about 15 minutes ago (from the time I am writing this) and about 10 minutes or some from when the VM was built.

While I was waiting for this, I realized I have a huge problem. The modules on the Pull Server that need to be transferred to the new VM aren’t in the right place, or in the right format. Per the DSC E-Book: “There’s a specific naming convention required for modules deployed to a pull server. First, the entire module must be zipped. The filename must be in the form ModuleName_version.zip. You must use New-DscChecksum to create a corresponding checksum file named ModuleName_version.zip.checksum. Both files must be located in the pull server’s ModulePath.” In somewhat good news, if I open the localhost.mof I created, it specifies the version of the Modules that I need to be present on my Pull Server. I am going to need the following Modules and Versions.

  • PSDesiredStateConfiguration, Version 1.0
  • xComputerManagement Version 1.2

In the interests of time I decided to just download all of the currently released Resources from one .Zip file found here and then just modify the two that I need for this specific example.  One thing I am not sure of is the PSDesiredStateConfiguration Module.  In the .MOF it’s name is just that, without the x.  But the Module itself when you download it is called xPSDesiredStateConfiguration, so I guess we will see what happens.


This gets even more confusing.  Doing some digging, the xPSDesiredStateConfiguration resource is on Version 2.0 on TechNet.  Running Get-DSCResource there is both a PSDesiredStateConfiguration Module and an xPSDesiredStateConfigurationModule.  Running Get-DSCResource on my VM I see that the PSDesiredStateConfiguration Module is already there (as it should be on Server 2012 R2).  The very first line in my Configuration is to import the xSystemSecurity Module, so I am going to need that as well.  Interestingly enough, this is what the .MOF file shows for that instance of my Configuration.

The Module name itself is PSDesiredStateConfiguration, but in SourceInfo it says it needs xSystemSecurity. You can color me confused right now. I am going to add that to my zipped Modules, just because I feel like it should be there. The xPSDesiredStateConfiguration doesn’t need to be there, but I am going to leave it there because it’s not going to hurt anything.

I am now going to force the server to pull it’s Configuration using this command (again, from the DSC E-Book).

And I get this handy error message!

Which is a load of crap because as my screenshots clearly show, the module is there! And as this screenshot shows from my Pull Server, it is the correct Module (and version).

Knowing some issues I had previously, I decide to reboot both the Pull Server and my VM. While my Pull Server reboots I was looking in the DSC Operations Log on the VM and found this message from when I forced the Configuration, so this working as expected at least.

I AM AN IDIOT. I DON’T HAVE A CHECKSUM!!!!!!!!!!!!!!! EVEN THOUGH I WROTE ABOVE THAT I NEEDED ONE!!!!!!!!!!!! ARGGGGGGGGGGGGGGGGG!!!!111!!111! But seriously, it would be nice if the error message said “hey, you don’t have a checksum” instead of that it cannot find the module.
So, after that. I run the commands shown below and have all my Checksum files!

Back on the VM I run the Invoke-CIMMethod @params command, and I get some good, and some “bad”. First the good!

Well, that means at least UAC got turned off in the Configuration! However, you can also see from the red text behind it that not everything went as expected.

Which is wonderful, because this literally tells me nothing. Also, the LCM is set to Reboot if needed, so it should have rebooted (I am guessing it didn’t because the Configuration failed at some point).

According to the DSC Operations log on the VM, this is what happened.

Well, I only have one RoleResource in my Configuration, so let’s look at that. The C:\Scripts folder was created, but the error states that it needs a file name. And then I see it. My LogPath parameter in my WindowsFeature BITS block just has C:\Scripts, with no file name. I change that line to C:\Scripts\Bits.txt. I then go through all of the same steps I did above to recreate the .MOF, copy it to the Pull Server, and Generate a New-Checksum (I remembered!).

Back on the VM, I force a pull again and………..

Now, the server didn’t reboot, but it was already waiting for a reboot from before, so maybe that is why? That is something else I will need to clarify with the DSC team. But for now, I am happy! After the reboot the VM was also joined to the domain, just as it should have been!