I want to transfer more and more logic away from Group Policies towards Windows PowerShell Desired State Configuration (DSC). There are several reasons why i think that DSC is much better than my old (and complex) group policy constructs, but the main reason (at least for me): I can manage DSC clients that are domain joined, not domain joined, or even Azure Active Directory domain joined the same way.

This is also something I use for Edge servers (like Skype or Exchange); they are not domain joined. And if you have more than one that should do exactly the same, this is where DSC could become a life saver and make your life very easy.

I play around with several DSC Push and Pull server instances, but I wanted to have the same set of DSC resources available on all of them. At least until I know which to keep to reduce my own logic.

I use the DSC Script Resource a lot. I do a lot of checks and implemented a lot of logic and flexibility within a lot of Script Resources.
However, this is the wrong way to use DSC! At least, in my opinion!

There are some very cool ready to use DSC resources available, and this reduces the script resource usage (or what I did: abuse). Why should I keep my own logic when someone else created nearly the same as a central and maintained DSC resource?
I know: I’m lazy!

So I created myself the following initial script:

You could use the same logic to install nearly all modules from the Gallery (or any another valid PowerShellGet Source).
This is something I do via DSC later and based upon the group that the DSC client belongs to; this could be a long list, or even a very short one.

The code is provided ‘as is,’ with all possible faults, defects or errors, and without warranty of any kind.