Yep, that’s a known issue right now with the WMF 5.0 preview (not limited to Windows 10). Microsoft is aware of it, but I’m not sure how they’re going to resolve the problem yet.
As long as you compile your MOF files from a WMF 4.0 computer, you should be fine. To my knowledge, there’s no problem pushing those MOFs from a WMF 5.0 system; it’s just the contents of the MOF that have changed (and are currently not backwards-compatible.)
Its actually an issue with DSC in WMF 5 which is installed in Windows 10. Two extra lines are added to the MOF file eg
instance of MSFT_FileDirectoryConfiguration as $MSFT_FileDirectoryConfiguration1ref
{
ConfigurationName = “WinConfig1”;
};
instance of OMI_ConfigurationDocument
{
Version=“1.0.0”;
Author=“Richard”;
GenerationDate=“09/20/2014 19:03:06”;
GenerationHost=“W12R2DSC”;
Name=“WinConfig1”;
};
The extra lines are the Name= and Configuration= lines above.
If your target is running WMF 4 (PowerShell 4) DSC will throw an error when you try to apply the configuration. Simply remove the 2 lines and you’re good to go
This is known by Microsoft as the September preview of WMF 5 is the same PowerShell build as Windows 10 preview and they are working on fixing the issue.
If you push to a server running WMF 5 September preview you won’t see the problem
I think it actually adds the ConfigurationName property to every instance of a resource you create. So in a large configuration it’d be painful to manually remove.
I like cleaning up the .mof files because it will continue to be an issue when we start transitioning to WMF 5 (unless they patch WMF 4 to accept the newer files).