DSC to difficult for newcomers

[jachin84]

Note this was taken from a discussion on slack and it was suggested that here would be a better place to capture the feedback.

This has been a bit of a journey and I really wanted to provide some candid yet constructive feedback for the Dsc community in the hope that this can be easier. I just made a class based DSC resource to do this Get-WmiObject -class "Win32_TSGeneralSetting" -Namespace root\cimv2\terminalservices -Filter "TerminalName='RDP-tcp'" | Set-WmiInstance -Arguments @{SSLCertificateSHA1Hash = $CertHash}.

This was WAY more complicated than I expected. For some context the line above is from a script that does some basic setup on a VM after it's provisioned in Azure. I'm converting the script to DSC. The line above sets the certificate for Rdp so we're not using a self-signed certificate. So lets's go through the process to convert that one line to DSC.

1. Is there an existing Dsc resources that can do this? - This is more complex than you'd think. Find-DSCResource doesn't really give you a good way to filter. Find-DSCResource -Name *rdp* didn't work. I don't think wildcards work in the Name parameter. Find-DscResource | ? Name -like *remote* looks better. The RemoteDesktopAdmin resource seems to do some stuff with Rdp, lets looks at that. Ok, that doesn't have anything for the certificate so keep looking. In general discoverability is hard. I think the PowerShell Gallery should be expanded to provide better searching for Dsc Resources and what those resources can and can't do. The only real way to tell for many is to look at the code.
2. Do I create a custom resource or not? - What to do in the scenario that there is no existing resource isn't exactly clear. I see a lot of examples where people use the Script resource and I've seen a large number of examples where the entire DSC configuration is made up of the Script resource. This seems a little strange to me and I would argue there really isn't any point in that approach, just write a regular script and call it a day.
3. Create a custom Dsc Resource - This seemed like the next logical step and there is a bit of documentation around, Get() Set() Test(), how hard could it be.... Wait, to make a Dsc Resource I need to put it in a Module, ok how do I do that? Ok manifest, folder structure, psm1, I think I'm good to go! How can I test things thing. The cycle time for testing a resource by actually running it is too long (copy to machine, build configuration, run configuration, return to editor, repeat). So what do other people do?? Pester. Hmm...ok. This is when I started looking at ModuleBuilder, PSDepends, InvokeBuild, Pester, Sampler. Who knew there is an entire ecosystem of build tools for modules.
4. Build tools and Testing - Ok so I'm building a module, I've got things split up into Public, Private, Classes etc, how do I build my module? Hours and hours later I can press Ctrl+B in VS code to stitch my module back together. But what about Tests. What's this Pester thing? Ok unit testing in PowerShell is Pester, hold while I go learn Pester. Woah this Pester thing is huge but I need to learn it because there doesn't seem to be another way to test a DSC resource in a module short of running it.
5. So my single line of PowerShell to set an Rdp certificate is now a custom dsc resource with hundreds of lines of code, numerous external dependencies, a build process, Pester tests and if I have time to spare I can put it into my CI/CD tools to make it look like this is all really easy.

This makes no sense. The value proposition for converting my script to Dsc suddenly looks a lot different. Don't get me wrong, the intention here is not at all to detract from the excellent work the community is doing but hopefully to capture some of the pain points so we can make it easier.