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?
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!
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?
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. 
“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.
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.