Questions with DSC reporting and the Test-DSCConfiguration -detailed

This topic contains 4 replies, has 2 voices, and was last updated by Profile photo of Don Jones Don Jones 10 months, 2 weeks ago.

  • Author
    Posts
  • #34255
    Profile photo of Ed O'Connor
    Ed O’Connor
    Participant

    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

  • #34260
    Profile photo of Don Jones
    Don Jones
    Keymaster

    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 🙂 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.

  • #34261
    Profile photo of Don Jones
    Don Jones
    Keymaster

    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.

  • #34269
    Profile photo of Ed O'Connor
    Ed O’Connor
    Participant

    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.

  • #34270
    Profile photo of Don Jones
    Don Jones
    Keymaster

    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.

You must be logged in to reply to this topic.