Prevent dependent resources from executing

I currently have a script resource that if it does not run the SetScript I don’t want the rest of the resources to be run. A way I could do this would be to throw an exception or maybe an error code and then the other dependent resources would not be run but this doesn’t seem to be the right way to do it and it would result in errors being shown which I would not want. I can’t input any logic around the resources to determine this because it needs to be decided after the MOF has been generated. Is there another way I can not make the subsequent resources run? I feel like this whole situation may not be a good approach to the problem. Any help would be great, thanks.

DSC resources have an automatic property called DependsOn which goes into the MOF document and does exactly what you’re describing. However, you will need to produce some sort of error in your Set script in order to communicate to the Local Configuration Manager that the Script resource was not applied successfully. There’s no way to have a resource’s Set method “silently fail”; all such failures are logged.

Your configuration script would look something like this:

configuration SomeConfig
    node SomeNode
        Script someScript
            GetScript = { }
            SetScript = { }
            TestScript = { }

        OtherResource theOtherResource
            DependsOn = '[Script]someScript'

I’m aware of the depends on property, is there no alternative best practice type solution? I want the output to stress that this particular behaviour of the script is not actually an error without all the red text.

The DependsOn property is the only control you have over how different resources are orchestrated in a configuration. If you need something more complex than that, you’d have to write a custom resource (or use the Script resource, as you already are) which contains all of the logic and behavior you’re describing.

I’m not really sure what you’re trying to accomplish here, overall. DSC Resources are supposed to be idempotent. If a configuration has already been applied (and nothing has been changed), then your other resources will all return true from their Test methods, and the Set methods won’t run anyway. There shouldn’t be any need to abort a configuration part-way through, except in the case of errors.

There is not only no “alternative best practice” solution, there is NO other solution. If you want to ensure that several settings do not run until another one has run, then you use DependsOn. That’s the way the technology is designed to work.

DSC isn’t designed for “output,” so perhaps I’m confused as what you’re trying to achieve.

What I think you’re asking is, “if I run into a situation where my Set script cannot complete, how do I signal DSC to also not try and run several other dependent resources?” The answer is, DSC doesn’t rely on the Set script to evaluate DependsOn. It relies on the Test script. If the Test script reports False, then DSC will not attempt any other resources that are set to DependsOn the failed one. But, as Dave notes, the Set script should return an error if for any reason it isn’t able to configure the system as desired. That’s the way DSC is designed.

That said, if DSC is set to AutoCorrect, it will repeatedly run Test and, if it gets False, immediately try to run the Set. So if you have some condition that the Set script isn’t dealing with, then you’re doing to wind up burning a lot of cycles repeatedly trying to run Set.

It might help if perhaps you provide a bit more description about what you’re trying. It’s possible that DSC is not, as you originally asked, the right tool for your job.

But it’s important to remember that, when run under the LCM, there won’t be any “errors shown.” MOFs aren’t processed interactively. Nobody’s going to “see” the error your Set script produces, except you when you’re testing.

Thanks guys. I’m going to use the depends on solution and produce an error. I’ll try and explain what I’m doing anyway, I do feel that my solution has become a bit messy and probably trying to do too much which is why this problem has arisen and it’s made my feel quite dirty, I’ll explain it as simply as I can:

I have a couple of zip files that are transferred using File resources. I then use Script resources to unzip those files. (I don’t use the Archive resource as it seemed to extract the files individually across the network). A service is created with another Script resource which uses the extracted files and is then started with the Service resource.

Unzipping the files the way that I do using the script resource introduced the problem that any subsequent deployment of that configuration would result in attempting to overwrite the extracted files that were being used by the service. It is not desirable to stop the service during this time. But due to the possibility of needing to update the files, I introduced versioning. This is just done by a file that gets moved by a File resource with a version number which a Script resource checks it at the beginning of the configuration. This script resource is the one I’m referring to in the original question: if the version is determined to be the same then don’t run any resources, if it is not the same and an update is required then stop the service and carry on with the other steps again.

I know that the file/archive resources can be used to work out whether a file needs to be changed but I needed to transfer a zip and unzip using the script just due to the size of the uncompressed files.

With regards to the “output”, when someone else runs the configuration I’m worried that when they see the errors stating that certain resources were not executed they will assume something has gone wrong. But maybe I have misunderstood what you meant by ‘when run under the LCM, there won’t be any “errors shown.”’ When they run Start-DscConfiguration they will see these errors? Hopefully this has made some sort of sense. Thanks for your help guys!