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.