Hello Brad,

One way to solve this would be:

To have a policy do a warm boot (using a bundle) of the device using a Time condition and

Another policy to uninstall the above bundle.

The steps involved would be as:

1.       Create a bundle containing the reboot package to install it

2.       Create a time condition to for it to run at say once every night

3.       Create a ongoing policy out of the above bundle and time condition

4.       Create second bundle to uninstall the reboot package

5.       Create another ongoing policy using the second bundle

 

When the first policy becomes complaint then the other will become non complaint and vice versa.

 

Hope this helps.

 

Regards

Rudra

What Rudra suggests would almost work, but in order for it to work correctly, the two Policies would have to effectively reverse each other.  The key is that after a Job is executed for one Policy, the second Policy must become non-compliant, and vice-versa.  For example, consider if Policy A installed Package X version 1 and also has a Warm Boot Step in the same Bundle, and Policy B installed Package X version 2 and also has a Wam Boot Step in the same Bundle.  Each Policy then requires that a specific version of Package X be present.  When a Job for Policy A is executed, it will become compliant, since the device now has version 1 of Package X.  But Policy B will be non-compliant, since the device does NOT have version 2 of Package X.  Note that without the use of a Condition to control WHEN Jobs are executed, this kind of thing would create a Policy Loop that would cause non-stop "flip flop" execution of Jobs for the two Policies. Note also that this would cause a Job to be pending "all the time" for the device, since one of the two Policies would always be non-compliant.  This means that every time the device checks-in, it will download the pending Job and evaluated the Conditions attached to it.  if the Conditions are NOT met, then the Job will not be executed, but it will be downloaded and checked EVERY check--in until it is met. One way to make this more efficient is to use a Detached Condition instead of a Readiness Condition.  This will cause the Job to be dowloaded, since there are no Readiness Conditions, but not executed until the Detached Conditions are met.  This avoids repeated download of the Job and also means that the device can and will execute the Job once the Detached Conditions are met, even if connectivity is NOT available at that time.  Note that the use of Detached Conditions requires an MSP Agent that supports Detached Jobs.  Please consult the documentation for information on selecting the proper MSP Agent.

Allan, I think what I'll do is create another 'Control Module' that in its check-in routine is to evaluate a pre-determined time value in the registry.  If conditions are met, then execute another lightweight warmboot utility using CeRunAppAtTime found in CoreDLL.dll.  I can in effect schedule a warmboot locally using the MSP agent say 15 seconds in the future, of course giving the agent enough time to finish its check-in routine.  I've had good success with CeRunAppAtTime, ever used it? I'd sure like to see a nightly reboot function build into the MSP agent, like a housekeeping routine of sorts.  Just a thought. What MSP lacks keeps me busy re-inventing the wheel. Brad