DSC Observations

PowerShell Help
1

I got around to building a couple of new VMs so I could play with DSC this evening. As luck would have it, right off the bat, I stumbled across couple of errors that have had me scratching my head for a couple of hours before I finally figured out what was going on. I set up a pair of Windows Server 2012 R2 machines, one to be a DSC pull server, and the other to be the guinea pig. I set up the pull server, mostly according to Steven Murawski’s instructions, and configured the LCM on my other machine (instructions.)

I wrote a simple test configuration file to install a server role, created the mof file and checksum, and so on.

First, I got the error referred to in this Connect report: https://connect.microsoft.com/PowerShell/feedback/details/802280/dsc-lcm-in-pull-mode-requires-a-current-config-set-through-push-before-pull-will-work . Annoying, but easy enough to work around given the instructions there.

This second error, on the other hand, was weird. I got this when trying to apply my configuration (with both push and pull methods, and even if I copied the mof file to the target server and ran the commands locally):

The PowerShell proivder MSFT_RoleResource does not contain the corresponding MOF file C:\Windows\system32\WindowsPowerShell\v1.0\Modules\PSDesiredStateConfiguration\MSFT_RoleResource.schema.mof.
    + CategoryInfo          : ObjectNotFound: (root/Microsoft/...gurationManager:String) [], CimException
    + FullyQualifiedErrorId : ProviderSchemaFileNotFound
    + PSComputerName        : TestServer.TestDomain.local

Web searches on that turned up zip. The schema.mof file exists, but it’s in a subdirectory of PSDesiredStateConfiguration, and there was no explanation as to why it was looking in the wrong directory. I was able to apply the configuration successfully to my DSC pull server, though; it was only failing on the intended target.

A while later, I tried compiling the same configuration to a mof file on the target server, and tried again. This time, it worked fine. Comparing the two mof files turned up this difference in the MSFT_RoleResource instances:

# MOF compiled on DSC Pull Server:
ModuleName = "PSDesiredStateConfiguration";

# MOF compiled on target server:
ModuleName = "MSFT_RoleResource";

I haven’t got a clue why identical PS1 files are producing different MOF files, or why the module name of “PSDesiredConfiguration” works fine on my DSC pull server, but fails on the other machine. MOF files that contain the module name of “MSFT_RoleResource” instead of “PSDesiredStateConfiguration” work fine on both computers. I haven’t gotten around to testing other resource types in the default module, but I suspect they’ll behave the same way on my VMs.

If you come across the same error, check the ModuleName strings in your MOF file, and try compiling it on a different computer (or just update the ModuleNames in the MOF file manually, if that’s easier.)

On a side note, all instructions and sample scripts that I’ve come across for setting up a DSC pull server say to create an IIS Application Pool that runs as Local System. That’s a terrible practice, in general, and seems overboard for a simple REST API server. Based on the setup instructions, the only thing I could think of that would require rights above that of a basic user account is Write access to the \Program Files\WindowsPowerShell\DscService\ folder (most likely, only to the Devices.mdb file.) I’ve created a service account, given it Full Control to that folder, and set my Application Pool to use that account instead. So far, I haven’t run into any problems.

2

Did you install KB2883200?

3

Not yet, unless it was already included in the MSDN ISOs I downloaded (which seems unlikely, since it’s not a Service Pack.) Is there something in the rollup that’s specific to DSC?

4

Yeah. It’s what allows it to find the MOF file ;). They changed the folder structure for GA. The MSDN builds need the hotfix.

5

Cool, I’ll try installing the patch later today and see how it affects the behavior on both servers.

Edit: BTW, do you know if there’s an equivalent patch for WMF 4.0 on computers running an OS older than 2012 R2?

6

Looks like that was the problem. I had run Windows Update on the DSC pull server, but hadn’t patched the client yet. Installing patches (possibly the rollup you mentioned; don’t know for certain) caused the client to start producing and consuming MOF files that refer to module name “PSDesiredStateConfiguration”.

That’s kind of annoying. If you’re bringing up a new server, one of the first things you’d likely want to do is apply its DSC configuration (which may be responsible for installing patches or configuring Windows Update, among other things.) Producing MOF files that are incompatible with older / unpatched versions seems like a breaking change.

I’ll do some more tests later to see how older operating systems with WMF 4.0 behave when they’re given the different MOF files.

7

It depends a bit on the install media you use. The VL ISOs have the patch; the MSDN MAK ISOs don’t. But if you’re deploying a new image and doing it the Microsoft way, then you’re starting with a serviced WIM that would contain the patch already. If you’re not doing it the Microsoft way, then life does get vexing.

But that’s why SCCM (for example) has a built-in ability to continually apply patches to a WIM, so that each new VM you spin up automagically has the latest releases that you’ve already deployed to production. That way, un-patched systems don’t exist.

Systems with WMF 4 installed are fine. This was specific to 2012R2 and Win8.1. There was a period between GM and GA where they made a change to the folder structure DSC uses. The VL ISOs came out afterwards, so they include the fix. The problem is largely related to MSDN ISOs, so you’re not necessarily seeing something production-related.

8

Confirmed. I had a Server 2012 VM that was behaving the old way, but I’m pretty sure I had installed the WMF 4.0 preview version on that one. I reinstalled it, and everything’s looking good now. Also tested a Server 2008 R2 machine successfully.

The first error I countered (from this Connect post) was also resolved by making sure everything was patched to the GA release levels before trying to apply a configuration.

One other thing I’ve noticed: The ConfigurationModeFrequencyMins and RefreshFrequencyMins settings for the LCM appear to have minimum values of 30 and 15 minutes, respectively. You can set anything you like in the configuration / MOF file and it won’t produce any errors, but the effective values don’t seem to ever go any lower than that when I check them with Get-DscLocalConfigurationManager. Rather than waiting around for 15-30 minutes during my testing, I was able to force the LCM to do a pull configuration by running the scheduled task “\Microsoft\Windows\Desired State Configuration\Consistency”, which just executes the following CIM method:

$params = @{
    Namespace  = 'root/Microsoft/Windows/DesiredStateConfiguration'
    ClassName  = 'MSFT_DSCLocalConfigurationManager'
    MethodName = 'PerformRequiredConfigurationChecks'
    Arguments  = @{
        Flags = [uint32] 1
    }
}

Invoke-CimMethod @params
9

You might read through “The DSC Book.” A lot of this is covered.

For example (although not yet in the book), the refresh intervals have a set of rules around them, with one needing to be a certain multiple of the other. There’s a team blog post on that.

10

And I do believe I have the 15/30 minimum doc’d, although I’m not sure I’ve committed that copy. Gonna check in a minute.

11

I’d skimmed through the book in an earlier version; just read through it a little more closely. There are a few references to the KB2883200, though they were in different contexts. Might be a good idea to just put a brief note about Windows 8.1 / 2012 R2 near the beginning that says “Weird crap will probably happen if you don’t have this patch installed.” :slight_smile:

It’ll take some more time before I’ve played around with some of the other functionality (compliance server, custom resources, credentials, etc), but so far the book looks pretty good.

12

It was probably the skimming :). I don’t have a “blink” attribute in the doc, but it does have a callout that says:

On Windows 8.1 and Windows Server 2012 R2, make certain that KB2883200 is installed or DSC will not work. On Windows Server 2008 R2, Windows 7, and Windows Server 2008, be sure to install the full Microsoft .NET Framework 4.5 package prior to installing WMF 4.0 or DSC may not work correctly.

Made it bold, with a bordered paragraph - as much as I could! Hopefully folks will see it. I agree that it’s awkward to have to do that, though. I’m going to include a reference to the actual error, though - that might help Google fu.