You don't need to have "dueling" Policies, although that is ONE way to do it.  The key is that you need to have a Policy that is always Non-Compliant.  A Policy could be Non-Compliant because it is internally inconsistent.  For example, if a Policy installs and uninstalls the same Package, it will never stay Compliant because it can't ever meet BOTH criteria.  However, you accomplish it, when a Policy is Non-Compliant a Job will be sent, and that is what you want most here. As you probably discovered, a Condition is the thing that can delay the Job until the right time is met.  So, what you want is for every device to have a Job "Delivered" prior to the time when you want the device to Reboot.  Each time the device checks-in, it will see that Jon and evaluate the Conditions to see if it is OK to execute the Job.  If the Conditions are NOT met, it will try again on subsequent check-ins until it is.  If the Conditions ARE met, then Job will be executed, causing the desired action - in this case a Reboot. In your case, since you don't need to reboot a device that can't check-in, a Readiness Conditon will serve, since there is no reason to even download the Job content until the Conditions are met and you can count on being able to do so when the time comes.  But if you wanted to reboot the device even if it could not check-in at the appointed time, then a Detached Condion would cause everything to be DOWNLOADED ahead of time, but not EXECUTED until the Conditions are met.  That would make it reboot at the appointed time even if the WLAN were down, for example. You probably also discovered that you need something more than a Reboot step in the Bundle to allow it to become Non-Compliant, even if its a dummy package.

There are a number of ways you might achieve a nightly reboot using MSP.  None of them are likely very intuitive since this was not something MSP was designed to do.  But using other features, you could certainly achieve it.  Which method will suit your needs best will likely depend on a number of factors. First, what type of reboot are you looking to do - warm or cold? Second, do you want this reboot to happen at a certain time every day or do you just want to be sure that it happens every day? Third, do you need this to happen only when a device is able to contact the MSP Server or would you need it to happen every day even if the device is out of contact for multiple days? Fourth, what version of MSP are you using?

1) Either reboot should work.   2) It needs to be at 3am.  Devices could be in use from 5am - 2am everyday. 3) it only needs to happen if the device is connected.  The devices should be in the cradle and connected to wifi every night. 4) MSP 3.3.1 I spoke to David in support who was able to accomplish this with dueling provisioning jobs.  We both agreed that it wasn't the cleanest solution.  I have also provided the software partner with API calls for rebooting and checking the time.  He is looking into the option of creating a standalone app that will monitor the time and reboot the device when appropriate. Any additional suggestion would certianly be considered.