Holiday Gift – Desired State Configuration (DSC) Resource Kit Wave-1

Continuing with the tradition of holiday gifts to the PowerShell community, the PowerShell team has just released DSC Resource Kit Wave-1 – a set of PowerShell modules that contain DSC resources and example configurations. The various modules that are part of DSC Resource Kit Wave 1 can be found here.

When DSC was introduced in PowerShell v4, we shipped a set of built-in resources. However one of the important features of DSC is the ability to create custom resources in PowerShell. Our previous blog posts detail how to author resources and how to deploy resources. In order to encourage the community to create more DSC resources and help boot strap the authoring process, we are releasing this first wave.

We have introduced a new naming convention for these modules and resources – they contain an “x” in them like xWebAdministration, MSFT_xWebsite, etc. The “x” stands for experimental – which means these resources are provided AS IS and are not supported through any Microsoft support program or service. We will monitor these, take feedback and may provide fixes on a “fix forward” basis – that is to say we may simply republish with fixes in future. I am deliberately using the word “may” to indicate no guarantees of any sort. However, you are free to adapt these to your environment and make changes as necessary.

Description of Resources

To discover all the resources available as part of the resource kit, use the Get-DSCResource cmdlet:

We reserve resource and module names without prefixes (“x” or “c”) for future use (e.g. “MSFT_WebAdministration” or “Website”). If the next version of Windows Server ships with a “Website” resource, we don’t want to break any configurations that use any community modifications. Please keep a prefix such as “c” on all community modifications.

As specified in the license, you may copy or modify this resource as long as they are used on the Windows Platform.

Requirements

The DSC Resource Kit requires Windows 8.1 or Windows Server 2012 R2 with update KB2883200 (aka the GA Update Rollup). You can check whether it is installed by running the following command:

Once the resources are deployed, they can be used in configurations. An example configuration is given below (this example together with the sample website files are available as part of the examples of xWebAdministration module):

Note: Any resource that is not shipped as part of Windows, needs to be available in a module in PSModulePath and must be imported (using Import-DSCResource keyword) before it can be used in a configuration.

Feel free to leave your feedback in the comments section as well as use the Q&A section in the TechNet pages. You can also provide feedback here in the connect page

> The PowerShell provider * does not exist at the PowerShell module path nor is it registered as a WMI provider.

I found something odd with this to do with the Machine level PSModulePath environment variable.

When "C:Program FilesWindowsPowerShellModules" is IN that path, Get-DscResource works & running the configuration script to generate the .mof file works, but running Start-DscConfiguration fails with the above message.

When "C:Program FilesWindowsPowerShellModules" is NOT IN that path, Get-DscResource can't find the resource, and running the configuration script fails, unable to import the module, however if the mof file has previously been generated, Start-DscConfiguration succeeds.

To workaround this, our build script is adding the path to PSModulePath for the first step, and removing it for the second.

We're looking into alternative ways to get the first step to succeed, so we never have to change the Machine level PSModulePath at all – but no luck yet.

Not sure if this quirk can shed any light on the root cause of why us and others are getting this error message.

Effective immediately, we've fixed the missing resource problem in xWebAdministration 1.3.2.4. All missing files/directories should be back in all TechNet zip files and on the Gallery. Sorry for the confusion and the delay.

I copied the example configuration provided to set up a new IIS website. 1st of all, I get a quiugly broken redline on xWebsite, indicating "Undefined DSC resource 'xWebsite'. Use Import-DSCResource to import the resource.

"Import-DscResource -Module xWebAdministration" is declared in the begining of the script, when I run the script I get

"The term 'Import-DscResource is not recognized as the name of a cmdlet………."

I searched this site, followed, what I was able to understand that fix KB2883200 is is "InstalledOn = 3/24/2015", yesterday.

Issuing Get-Dsecresource, I can see clearly 2 modules, "xWebApplication and xWebVirtualDirectory".

Also, I discovered that Import-DscResource is not recognized neither on the commandline nor in the help in ISE

What can be missing? Thanks in advance

3 years ago

Aaron Jensen

So, I, too was getting this error:

> The PowerShell provider * does not exist at the PowerShell module path nor is it registered as a WMI provider.

for one of my moduels on a server that previously was working and downloading stuff. Rebooting didn't work. Killing WMI processes didn't work. It turns out, I had changed a .mof file without updating its checksum. As soon as I updated my checksum, things started working again.

While sorting out why my custom resource was not being recognized I went to apply a configuration that has Import-DscResource within it and I received the following error on a Server 2012 R2 machine when I process the configuration to create the MOF:

PS C:UsersAdministrator> Import-DscResource

Import-DscResource : The term 'Import-DscResource' is not recognized as the name of a cmdlet, function, script file,

or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and

I have no idea what happened. Unless something was uninstalled while processing an 'absent' of my application.

4 years ago

Peter

I saw the same issue as Mark and gt where I was getting the error message that the PowerShell provider does not exist at the PowerShell module path nor is it registered as a WMI provider when I ran Start-DscConfiguration. In my case, I was using the xHyperV module. I stopped all the WMI processes hosting DSC engines but that did not help.

Interestingly, after I rebooted the system, the error disappeared.

2 years ago

Brandon

A reboot fixed this exact same issue for me too. I was able to generate the MOF file, but unable to apply the configuration using Start-DscConfiguration. Once I added the module path to the PSModulePath environment variable and rebooted, everything worked.

Regarding the above issue, I wanted to confirm that y'all were using: "Import-DscResource -Module MyDscModule" in your configuration. Not including the explicit import can cause the issue that you were describing.

To be clear – you should not have to install custom DSC modules into the system directory.

Just so I’m clear on the details of your problem, I’ll try to restate what you said above:

• When MyDSCModule is in C:Program FilesWindowsPowerShellModules, you can import MyDSCModule using Import-Module.

• When MyDSCModule is in C:Program FilesWindowsPowerShellModules, you can “compile” a configuration using MyDSCModule into a .mof file (e.g. running configuration “MyConfiguration” to generate the MyConfiguration folder)

• However, when you actually try to “apply” the MyConfiguration.mof to localhost, you encounter the above error.

This is an odd problem. Because you can successfully compile the .mof:

• Your problem does not appear to relate to the Update mentioned above (KB2883200).

• Your configuration is probably not malformed in any way (e.g. missing Import-DSCResource –module MyDSCModule)

Because it works when MyDSCModule is in the System Directory:

• The MyDSCModule on the target node should be the same version as the one used to generate the .mof.

Is it possible that you have multiple versions of MyDSCModule deployed to different areas of the module path? Is there any way you can share you configuration with us by uploading it to CodePlex or a similar site?

Thanks,

John Slack

Program Manager

PowerShell Team

4 years ago

Mark Johnson, Esquire

I am having the same issue as "gt". When I put my DSC module in the recommended path of "C:Program FilesWindowsPowerShellModulesMyDscModule", the

Start-DscConfiguration -wait -Verbose -Path "MyConfiguration"

Fails with the message :

"The PowerShell provider MyDscModule does not exist at the PowerShell module path nor is it registered as a WMI provider.

I am able to import the MyDscModule in PowerShell using "Import-Module MyDscModule"

I verified the $env:PSModulePath variable contains the path "C:Program FilesWindowsPowerShellModules" and the value is stored at the "Machine" scope ([environment]::GetEnvironmentVariable("PSModulePath","Machine"))

If I move the module to "C:windowssystem32WindowsPowerShellv1.0ModulesMyDscModule", then the Start-Configuration command works fine.

I did kill the wmi* process as outlined above.

I really do not want to install our custom DSC modules into the system directory.

@gt – You need to have a xComputerManagement.psd1 file under xComputerManagement folder for it to be valid module. Are you missing that?

4 years ago

gt

@powershell team , thanks for the help much appreciated , we tried running the get-process command gps wmi* | ? {$_.modules.ModuleName -like "*DSC*"} on the localhost/target machine where our custom DSC resources reside but it returns nothing.

Quick question unzipping one of the examples into <$env:psmodulepath> C:Program FilesWindowsPowerShellModulesxComputerManagement

get-dscresource shows for this resource

Name Module

xComputer xComputerManagement

we generate a localhost.mof file ok and it contains ModuleName = "xComputerManagement";

we run the command start-dscconfiguration -wait -verbose -path c:dsconfiguration

The PowerShell provider xComputerManagement does not exist at the PowerShell module path nor is it registered as a WMI

provider.

what do we need to do for it to locate the module as there is no xComputerManagement.psm1 file in the parent directory , how do we tell the DSC engine to look in .DSResourcesMSFT_xComputerMSFT_xComputer.psm1 where the logic is for get/set/test

@gt – Did you updated the resources on the target machine as well? You might have to stop the WMI process on target machine that is hosting DSC engine for updates to be reloaded. You can find it using the following expression