Questions with DSC reporting and the Test-DSCConfiguration -detailed

All,

I am in the process of testing/evaluating DSC and the director at this company is not liking the lack of reporting that DSC provides. One of his main concerns is that he does not see a way prior to deploying DSC to see what changes DSC is going to make. Say we are going to deploy a DSC configuration to some nodes, he would like to know prior to deployment or prior to any changes being made what changes will be made on a said node based on its current configuration. Does anyone know of a way to do this via DSC? So far I have only been able to tell him that we need to run our our reports of the servers configs prior to DSC and then compare to the DSC config.
Second, I am working with the Sept 2015 preview of MGMG framework 5 and the Test-DSCConfiguration -detailed and am trying to clean out the output so it can be used to what is in DSC Compliance and what is not. The output from this command is basically unreadable. It puts all the ‘ResourcesInDesiredState’ and ‘ResourcesNotInDesiredState’ in one array/line. One a large config this is unusable.

Here is what I have tried to no avail:

$InDS = {$_.ResourcesInDesiredState}
$NotInDS = {$_.ResourcesNotInDesiredState}
$Seperator = ","
$NewLine = $InDS -split $Seperator

Test-DscConfiguration -detailed | select-object PSComputerName,{$NewLine},ResourcesNotInDesiredState,InDesiredState

I realize that the ‘ResourceNotInDesiredState’ portion hasn’t been flushed out. I figure once I get the ‘ResourceInDesiredState’ worked out I can just duplicate the process. Any and all help is greatly appreciated.

Thanks,

Ed

Well, it’s really a question of what DSC is meant to do, and what it isn’t. Keep in mind that it won’t change anything that it isn’t told to. But, once you’ve told it to change something, you should assume it will change that thing.

If this is just a, “we don’t know what situation the computers are in, so we don’t know what DSC will end up doing,” that’s not the… attitude… DSC was created with. You’re not (from its perspective) supposed to care what it does, you’re supposed to care about what the computer looks like when it’s done. This is about policy-based management, not procedural management.

I know the cultural shift is a huge one, but you do have to be a bit careful about trying to bend DSC to be something it isn’t, because you won’t enjoy the experience.

So I’d argue:

“he would like to know prior to deployment or prior to any changes being made what changes will be made on a said node based on its current configuration.”

Why do you care? If the DSC configuration is what you want the computer to be, then all you should care about is whether it’s like that or not. And that’s what DSC takes care of. I do realize, Ed, that this isn’t you asking :slight_smile: but with DSC in particular it’s important to understand what it’s built to do, and what it isn’t.

DSC isn’t intended to tell you what your computers look like, it’s intended to make them look like what you want.

Regarding the Test cmdlet’s output… yeah, I’m not sure that’s as fully fleshed-out as the team would like, either, right now. But, you’re not going to get a “clean” report using a one-liner. The reason is that some of the output properties are actually collections, and you’ll need to expand them. For example, try piping the command to Format-Custom -Depth 10 and see how the breakdown goes.

BTW… to continue to expound on something that’s likely unhelpful :)…

I’ve run into customers who have the attitude of, “look, I just want to know what it’s about to do, so I can figure out if it’ll break anything.” Which is what test labs are for, and that’s an excellent thing to model. P2V a candidate node, drop the DSC config on it interactively (Start-DSCConfiguration -wait -verbose) and see what happens. Gain confidence, and then fire it into production.

Thank you Don, I appreciate the response. I had told given the Director a similar response to what you said about what does it matter what state they are in if this is the desired state we want. I just wanted to ask to make sure I wasn’t missing something.

Thanks again.

Always happy to help ;).

FWIW, I’m hoping once MS starts spinning up some tooling, someday, we’ll get better reporting from Test-. Right now it’s definitely a little raw.

I have had this post bookmarked for quite a while :slight_smile:

I am incredibly excited to announce the open source release of DSC Environment Analyzer (DSCEA), a PowerShell module that uses the declarative nature of Desired State Configuration to scan systems in an environment against a defined reference MOF file and generate compliance reports as to whether systems match the desired configuration.

DSCEA is a project that Keith Hitchcock and I created as a part of our work with our customer, and we are now releasing it publicly to the world today. We have seen great value using this solution and hope that you will take a look to see if this could apply to your work with your customers.

For more information, check out:
https://blogs.technet.microsoft.com/ralphkyttle/2017/03/21/introducing-dscea/

We are always looking for contributors who are interested in helping out. Even if you feel that helping on the code itself isn’t your thing, we are looking for all thoughts and feedback that we can find. Please let us know what you think!

Thanks,
Ralph Kyttle