Some of the most thought-provoking conversations I have with other IT professionals and PowerShell aficionados have stemmed from discussions around DSC configuration design. In these discussions, it is not the technology that is up for debate. It is the thought process and how different people set about tackling a problem that is in question. You can learn a lot from other people when it comes to problem-solving. This is especially true when they think differently than you do.
Sometimes, you may believe that everyone else thinks like you. Through discussions with others, you realize that is not the case. You also learn unusual ways to think about a problem. This can help you become a better programmer in the long run. In this article, I am going to discuss my own thought process for solving a problem using DSC. I will also document the tools and resources I use when developing a DSC configuration.
It is a common misconception that you should jump right into writing that DSC configuration. You may need to touch, explore, and see the problem before you can write the code. At times, this may even mean using the GUI. Doesn’t PowerShell mean never touching a GUI again? Says who? Let’s look at an example.
I wanted to use the DHCP Failover feature in Windows Server 2012 but I had never touched it or looked at it. Wanting to jump right in to creating a DSC resource for it, I found some PowerShell cmdlets for configuring it. I quickly realized that the cmdlets to set it up had many parameters and that I did not really know what some of the parameters were for. I used the GUI to explore the setup and different options. It is called research. As far as I know, there is no law that says I cannot use a GUI to learn how to solve a problem.
DSC Resources are built into the PowerShell platform. These should be your first stop for identifying a resource in your toolset when solving a specific problem. Microsoft builds them in for good reason. They are the most typical resources used when configuring a server. Built-in resources can be found in the PSDesiredStateConfiguration module and additional resources have been added with each new version of the Management Framework. Do not overlook these items. They are already in your toolbox. To see what resources are at your disposal, use the Get-DSCResource cmdlet.
Get-DscResource -Module PSDesiredStateConfiguration
Your next stop for DSC resources should be a trusted repository. For many, including myself, that means PowerShell Gallery. As a security-minded IT professional, I had a tough time trusting any online repository or code that was written by anyone other than myself or my co-workers. Since Microsoft maintains the PowerShell Gallery, it has processes for malware scanning and reporting abuse. This lessens the fear. This does not mean you should blindly trust the gallery. Your organization should weigh the risk of using another’s code with the work effort involved in writing your own code. Engage your security team and adopt policies for how your organization goes about vetting a module for use in your environment. Follow those policies.
The PowerShell Gallery contains so many resources. It may be difficult to identify if the desired resource is in there or not. You may become a keyword-searching expert before long. You can search by keyword or by tag. You can save time and effort by solving your problem using code that someone else already solved.
find-module *keyword* find-module -Tag DSC
When the built-in resources or the PowerShell resources will solve your problem, it is time to build your own custom code. Here are your 3 options:
I typically look to a script resource first. Why? I find that a script resource is the fastest way to find out if something is possible. When I write a script resource, I am defining exactly what I want to set and that is nothing more and nothing less. At that point, I do not have to figure out Ensure = Present and Ensure = Absent. I only have to decide, which of those two scenarios I want to handle. I do not have to copy modules to my target machine and I do not have to define parameters. Heck, I can hard-code my parameters and make it do exactly what I want it to do. It is the coding equivalent of a scratch pad.
I do not usually take code much further than the experimental, can-I-do-this phase. I only really move from a script resource to a custom resource when someone else wants to use the code. I may also do this if I want to show it to others. I currently have an extensive list of script resources to convert to function-based custom resources. Why do I choose function-based? I learned modular-based programming a long time ago. I learned this before object-oriented programming was really a thing. My brain grasps function-based programming a little easier than class-based programming. If I am looking for a challenge, I will give the class-based resource a shot.
This may seem like a no-brainer but it is far too easy to escape the confines of the actual problem in pursuit of solving other problems. I call this chasing squirrels. This is a problem that pops up during solving the initial problem. It is distracting me from the initial problem and causing me to lose focus. For me, this is usually making the scope of a script resource too wide. It is also immediately jumping into making a custom resource that handles every parameter, scenario, or setting possible. This is another reason why I start with script resources. I can keep the scope of the problem in check.
I am not pleading for anyone to use script resources. In fact, my friends and mentors scold me for using script resources in places where a custom resource would be much more elegant. If I were packaging code for production use, I would also prefer the modular resource. I would spend the time converting the script resource to a modular resource. I do know how my brain works and the script resource allows me to keep my scope limited. If I go straight to a custom resource, I will be dodging squirrels left and right. I will argue all day that this is the right choice for me. It may not be the right choice for everyone.