28 Days of DSC: Day 17 Class Based Resource Part 3 – The Final7 min read

Hey Guys!

Day 17! People think that I had all these posts prepared in advance and was just simply releasing them everyday. I am far to spontaneous to do something like that. I had the idea to create the series so I did, hence the timing of the posts varies massively. Sorry!

I put in a lot of effort to make sure the posts get out everyday, even it’s at 11:30pm ;). I hope you guys appreciate it and are benefiting from my efforts.

Anyway, to DSC and PowerShell Classes. The last 2 days have been strongly focused on PowerShell classes both generally and specifically to DSC. Since it is a topic which I feel a lot of PowerShell/Devops people aren’t familiar with, I’ve taken the time to explain it as simple yet as thoroughly as I can. Apologies if that isn’t the case.

I explained Inheritance in quite a bit of depth yesterday but I felt I was alot of theory and probably needed more real life PowerShell based examples in order to cement it in your minds.

The goal is to demonstrate some more complex, real life uses for classes. Not complex for the sake of being complex, rather beneficial and practical to the implementation of DSC and perhaps other Automation projects.

Let’s Begin

Very briefly said, Polymorphism is the concept that 2 separate pieces of code that express themselves the same way and yet behave differently.

Think about DSC and the fact that all DSC Resources must contain the get, set and test methods. In Theory the LCM doesn’t know or care particularly at all what our custom resources are. It simply knows because all Resources inherit from a single parent DSC Class. That it can call the get, set and test methods exactly the same for Microsoft written resources as for custom resources written by you or I.

By default we only have the means to directly inherit from one class. Potentially the class could inherit from another class and so on, but when I create my class I can only specify one parent class…or can I?

Unfortunately as of today (Or at least to the best of my knowledge), you cannot write interfaces in PowerShell. There is however, nothing stopping you using them. Being able to do this, opens up to us a world of opportunities.

See here, we can implement the IEquatable interface in order that we can write our own custom Equals method.

This might seem a little unnecessary but what we have now is an super easy way to check if two objects are the same. And since we are implementing the IEquatable interface it’s enforced.

Hopefully you can imagine now replacing our Compare functions with overloaded Equals methods. The functionality was there before also with PowerShell scripting but it couldn’t be enforced and it’s implementation was different every time.

The only downside to implementing Interfaces in PowerShell is that you need to have class inherting from somewhere in order for the generic to work. This is because the IEquatable is a generic class and it can’t find the dftaiADUser class while PowerShell is at the same time trying to creating it.
For me, I don’t think its that much of an issue since I’m likely to need shared properties and methods between all my AD classes anyway i.e. users and groups both have a Name and Description etc.

For the typical CRUD DSC Resource i.e. Create, Modify, Delete AD Users, we could create ourselves a completely generic class structure to handle all the functionality and have a very minimal dftaiADUser class.

This would be my suggestion.

Hopefully, this doesn’t seem all that complicated to you now, but the idea is that all the generic logic that we write every time for example in the get.

  • Build params to actually get object from AD
  • Execute Get
  • Build return object

These 3 are always there now. All you have to do it populate the 3 internal functions that do the heavy lifting.

Same goes for Set and Test methods. All the logic regarding testing if the state is valid or not, when to create, modify or remove. It’s all there.

To get this implemented with our dftaiADUser class, let’s see what it takes.

So here all we’ve done is:

  • add our additional parameters (Don’t forget, Ensure is defined in the dscbase)
  • fill out our buildparam/execute logic

Anytime we want to alter the logic or add more standard verbose messaging, we just go ahead and add it to the base class.


I know that is a lot of information and potentially a lot of new topics. However, at the same time I hope you understood what I was trying to get across.

For me this was a completely new way of looking at PowerShell and DSC. I didn’t know anyone else that was working in this way and so I’m trying to spread the word.

Maybe you think I’m crazy? Maybe I am? Either way, let me know you thoughts either publically on Twitter or by mail ryan@dftai.ch

I hope this has been a useful post for you. If you are currently using PowerShell Classes, Tweet me and let me know how you’ve got it implemented using the hashtag #28DaysOfDSC.

If you’ve missed any of the other posts from the 28 Days of DSC series, check them out here.

If you have any questions or suggestions for topics to cover in the series, hit me up on twitter.


and Don’t Forget To Automate It!

Leave your comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.