I'm going to keep this one relatively short and explain how ReverseDSC was designed to work and how it can be improved. All the while laying the ground work for creating our own ReverseDSC Scripts.
I just want to go through a start to finish example of how you can take an existing project and extend its functionality. Forking, committing, merging and pull requests
Since they are a mixed between business logic and external function calls, we call these grey box tests, but since that would of made for a boring picture, I coloured them red 😃🎨
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.
The idea behind Partial Configurations is that you can separate the responsibility of each part of you configuration into entirely separate MOFS (Configurations)
In it's default state, DSC can only be administered by the local admins of the windows machine. This can be problematic if you want to assign lower privileged users.
Today is simply discussing the structure of a DSC Resource. How it works, setting it up, and some things to start thinking about before we start coding.
Nested Configurations are to DSC what functions are to PowerShell. You can reuse them in your configuration script to save you typing the same thing over and over.
ConfigurationData is the way in which we pass variables into our DSC Configuration scripts. This post aims to provide a couple of tips on how to make using configdata a little easier.
A DSC post for every day in February. Clear, concise, specific DSC posts which will hopefully improve your DSC configurations, resources and troubleshooting no end.