Intersecting DSC Configuration Design and Personal Style
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.
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.
Acknowledging Differences in Thought Processes
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.
Gain Experience with the Technology
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.
Research, Research, Research
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.
Use What You Have First
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
Check Trusted Repositories
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.
Do Not Reinvent the Wheel
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
Identify the Gaps
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:
- Script Resource
- Function-Based Custom Resource
- Class Resource
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.
Make It Pretty
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.
Define and Stick to Solving the Problem
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.
Embrace Differences in Programming Styles
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.