DSC Push Configuration concept

This topic contains 5 replies, has 3 voices, and was last updated by Profile photo of Timor Kaleman Timor Kaleman 9 months, 2 weeks ago.

  • Author
    Posts
  • #35806
    Profile photo of Timor Kaleman
    Timor Kaleman
    Participant

    Hi, I would like to clarify an issue that I am having. I like to deploy a one time deployment through a push job but, I don't want that the LCM will continuously will try to run this job. My current status is exactly the opposite from what I want, It does run the job but the LCM continuously running the job on the refresh interval even though I haven't run it manally.
    Do you know which configuration I need to change to change this behavior?

  • #35807
    Profile photo of Will Anderson
    Will Anderson
    Keymaster

    Hey there Timor,

    You can configure the LCM's ConfigurationMode to 'ApplyOnly', which would process the current configuration once and do nothing more until it receives a new configuration. You can read up on the LCM configuration settings here:

    https://msdn.microsoft.com/en-us/powershell/dsc/metaconfig

    Let me know if that helps!

  • #35808
    Profile photo of Timor Kaleman
    Timor Kaleman
    Participant

    Thanks for the reply, Well I do use the "ApplyOnly" configuration but I see something strange, When I do "Get-DscConfigurationStatus -all" on the target server I have this job:

    Success 2/28/2016 10:42:26 AM Consistency PUSH False 37

    Which is different from other jobs like:

    Success 2/29/2016 4:01:21 PM Initial PUSH False
    Success 2/29/2016 4:01:07 PM Initial PUSH False
    Success 2/29/2016 4:01:03 PM Initial PUSH False
    Success 2/29/2016 4:01:02 PM Initial PUSH False
    Success 2/29/2016 12:36:44 PM Initial PUSH False

    Maybe the "Consistency" type make the configuration to run every refresh time?

  • #35811
    Profile photo of Will Anderson
    Will Anderson
    Keymaster

    Hey there Timor,

    If I understand it correctly (looking to some of the other kids in the class here for validation), the consistency runs if you push a configuration that you've already pushed to it. Try making a change to the configuration and re-push it, and it should come back as initial. I'll be testing this later this afternoon once I get finished beating up on some Azure Template stuff. 🙂

  • #35816
    Profile photo of Justin King
    Justin King
    Participant

    "Working as intended"?

    So the thing with DSC, is the reporting and testing are kind of integral to the way DSC was designed. If you just want to "push and forget" you might as well just be pushing a generic script. There's a reason we have test() and get() defined: DSC wants to be able to check the the status and report back.

    Setting to "ApplyOnly" may only run the set once, but it's still going to run consistency checks of its current configuration in regards to the last configuration pushed. That's what it's basically designed to do.

    The "consistency false" basically means that the node settings don't match what was pushed (or at least the test code isn't working). The error code 37 could be as simple as pending reboot ... but I"m having problem finding the page that holds all the error codes (I found it once before .... but google is failing me today).

    Basically your script ran but something is failing during the test.

  • #35840
    Profile photo of Timor Kaleman
    Timor Kaleman
    Participant

    Thanks Justin, Well I do want to get a feedback on the job that was run, but I would like it to run only once. Maybe I will explain my scenario more in detail so it will be more clear of what I mean.

    I am working in a critical production environment so all the DSC configurations must be controlled and audited and no auto-reboots are allowed on the daily. I've created a DSC configuration that deploys an application on multiple machines with some prerequisites like MSI packages. When I performed the deployment it began to install the 1st prerequisite on the first machine and than it stopped on "waiting for reboot" even though the actual MSI doesn't require a reboot. Then it began to deploy on the other machines and finished successfully. After 15 minutes (I presume it's the refresh cycle) it started the process again on the first machine and finished it successfully.

    It created me a problem because the deployment on the first machine had to finish first before the other machines get the deployment. I was wondering whether it's only a special case when the job stops on "wating for reboot" or the DSC always runs the job every 15 minutes, and if the first option is the case, how can I ignore the "wating for reboot" and continue the deployment.

You must be logged in to reply to this topic.