PowerShell DSC Journey – Day 7

Alright, so yesterday I was able to successfully create a very simple (and that is putting it mildly) DSC Resource. It currently only has only 3 parameters: Ensure, Depends On, and Name. Today I am going to start writing the Get,Set,Test Functions and testing them (hopefully).

Here are my 3 main references for this task:
http://blogs.technet.com/b/privatecloud/archive/2014/05/02/powershell-dsc-blog-series-part-2-authoring-dsc-resources-when-cmdlets-already-exist.aspx
http://blogs.technet.com/b/privatecloud/archive/2014/05/09/powershell-dsc-blog-series-part-3-testing-dsc-resources.aspx
http://blogs.msdn.com/b/powershell/archive/2013/11/19/resource-designer-tool-a-walkthrough-writing-a-dsc-resource.aspx
I am also referencing the MSFT_xVMHypverV.psm1 and other existing resources .PSM1 files for reference in helping me create my functions.

Since it’s the first thing in the list, I am going to start with the Get-TargetResource function. This should check and see if the Hardware Profile exists. If it exists already it should return 1 if True (Hardware Profile Name exists) and 0 if False (Hardware Profile Name does not exist).

First thing I am going to do is start with looking at the Get-SCHardwareProfile cmdlets. Which does not turn out the way I expect because it doesn’t take a name parameter, which is probably going to be a pain in the ass.

Looking in VMM GUI, I don’t see an ID anywhere for my existing hardware profiles. But looking at the examples in the help files shows that I can still use Where-Object Name -eq $Name to filter and I should be OK. I also realize that I am going to need a parameter for a VMM Server because that would be a horrible thing to hardcode. So I am going to backup and do that right now.

Adding this property is as easy as:

NOT!

So ModuleName, no longer exists. That’s ok, it looks like it’s now Name, and I need to change Properties, to Property, no biggie!

LOL WHAT? Fine then, let’s look at an example.

Fine. I will read the rest of the help. Somewhere Jeffrey Snover and Don Jones are crying and a kitten probably died. I need a Name and a Property and that is all that is required. It then occurs to me that this is a new PowerShell session, and it doesn’t have the variables for Ensure, DependsOn, etc stored. So I re-run that part of my script, run it again, and I get a different error!

Well. Like hell it’s not the name of the Resource!
dsc61

So, I have the bright idea to run this fancy command to see if it can actually find it.

And here is part of the output.

It now occurs to me that maybe it can’t update it because it hasn’t been imported? So let’s try that.

How can it be shown as an available Module and then not be able to import it because no valid module file was found????? I tried changing the Version to 1.0, and then importing it and that didn’t work (same errors).

After thinking about it some more, I think for some reason maybe the path just isn’t working (I borrowed the one from the blog article) and I am just going to change it to the Modules path with the rest of the DSC Resources. That also doesn’t work. I then try to import the Module from the new directory using Get-Module -Name and notice that intellisense doesn’t show it in the list. Something is definitely up. I then remember reading somewhere about how anytime you do this you also need to create a Module Manifest (or something like that) because it isn’t created by default.

After a lot of reading and not finding what I am looking for, I Googled “New DSC Resource Module Manifest” which led me to this article. It clearly states you need a module manifest, which I don’t have. Yet!

This is the important part of that section of the article. “Finally, use the New-ModuleManifest cmdlet to define a .psd1 file for your custom resource module. When you invoke this cmdlet, reference the script module (.psm1) file described in the previous section. Include Get-TargetResource, Set-TargetResource, and Test-TargetResource in the list of functions to export.” Looking at existing DSCResources however, they don’t specify those functions, they just have an *. In an effort not to complicate things I am going to go bare bones with this module manifest.

Sounds easy enough!

Whatever. I am going to just restart PowerShell ISE and see if that magically fixes it. And nope. It then occurs to me that maybe I’m an idiot and my Module name can’t have an underscore in it. So let’s try all of this without that. And it doesn’t matter. Same nonsense. This should not be this hard.

I do some more research, and run this command, which works completely fine. And then I try the one with the underscore, which also works. I guess that’s the way it is going to be? There is probably a reason for it, but I don’t know what that reason is. I deleted all my files and started over and went through all of this.

I just. I don’t get it. WTF is going on?????? I am looking at the help for Update-xDSCResource again and notice something interesting. In the Parameters it has -Name but in the example it uses -ResourceDirectory. However, there is no -ResourceDirectory parameter when I try that. So, then I try this.

And it freaking works. I clearly need to do more research into why I can’t just use the Resource Name when everything I read says I should be able to do it. I don’t get why I need to use the entire path there.

I look in the schema.mof and verify that it was in fact updated.

That’s enough for today. And maybe the rest of this week.

EDIT: Once I added C:\Program Files\WindowsPowerShell\Modules\DSCResources to my $Env:PSModulePath directory I was able to import the Module by name, without having to use the path. However, I still can’t update the Resource without using the entire path. Awesome. Not.