PowerShell Desired State Configuration (DSC) Journey – Day 11

Yesterday I worked with the File Resource to ensure that the path C:\Scripts existed and that my BGInfo files were inside of it.  Today I am going to attempt to use the Package resource to run the BGInfo Files.

First thing I need to do is find out what the settings for the Package Resource are.

There are 3 mandatory settings, Name, Path, and ProductID.  I did some digging around for information on what the ProductID requires in a situation like this, and didn’t find much.  So I am just going to make one up and see what happens.

Here is the code I added to my Configuration script.

I have the server Pull this configuration and it fails.  I am not going to show the entire thing here, but this is the relevant part.

So like I suspected it clearly does not enjoy my ProductID, but doesn’t tell me how long it needs to be or what the format should be (although I strongly suspect I know what they should be).

The example on the TechNet page for this resource as ACDDCDAF-80C6-41E6-A1B9-8ABD8A05027E so I will just use that format but modify it in the Configuration to see if that works.

I am going to try this for the ProductID and see how it works.  NFM12345-1234-NFMN-1234-OMA123NE1234 and NFM12345-1234-NFMN-1234-OMA123NE5678.

Nope, no dice.  Same error.  This leads me down a Google rabbit hole involving MSIEXEC and ProductID searches.  Then it dawns on me that there truly is no ProductID, so what if I just use “” for the Product ID?

Boom!  Both files work and BGInfo is installed.  The proper directory in Program Files is created, the proper file is moved into the Startup folder and the BGInfo is showing on the desktop.

Here is the final version of the code.

Looking at the list of built-in DSC Resources I haven’t touched yet, I think I am going to go with learning the Log Resource tomorrow.

7 thoughts on “PowerShell Desired State Configuration (DSC) Journey – Day 11

  1. The easiest way to discover a product ID – and only an MSI would have one – is to install it and look in Windows Installer (Win32_Product). You’re right in that a non-MSI installer, which doesn’t use Windows Installer, won’t have it. DSC uses the product ID to determine if the thing is already installed or not.

    It’s annoying that DSC resources can’t provide something like comment-based help to better describe what their settings are all about. I mean, I suppose they could, -ish, but given that the resource function names are all the same, it still wouldn’t be all that discoverable.

  2. Thank you! This had had me stumped, and Don’s comments answered more questions. I hope Microsoft improves DSC documentation.

  3. Thank you so much for the link to Don’s book! I had the good fortune of hearing a presentation by Jeff Hicks yesterday at the AZPOSH (Arizona PowerShell Users Group.)

    Since you had run into the same error I did (Cannot invoke the SendConfigurationApply method. The SendConfigurationApply method is in progress and must return before SendConfigurationApply can be invoked.), perhaps you will be interested in reading my own DSC diary post?

    The link is in the Website field.

    Best regards!

    Scott

    • Wow. That’s pretty incredible. I don’t even know what to say about that error. I haven’t ever seen that before myself. If you reboot your own computer does it still happen?

  4. Hi, Jacob,

    A guy gave me a tip on TechNet that he had experienced the error, and he felt it was due to “stale” MOF files. He removed them, made fresh ones, and was fine. I did the same and didn’t get the error again. I can’t say for positive that this was why, but it’s definitely something to remember.

Leave a Reply