Sure, go ahead and submit a GRIP, but if you want to increase the chances that we do it, please include details of what your exact requirements are and the details of any opportunities it would enable.  In general, when we develop Control Modules, we try and make them fairly generic so they can be configured to suit a variety of needs. The complexity of developing such a Control Module depends on how much functionality you try and cram into it.  The MSP Programmer Development Kit provides everything needed to develop custom Control Modules.  So, a very simple one, to provide only programmable reboot, would be easy to develop.  A very complicated one, with many configurable options and lots of possible actions, would be considerably more so.  When developing you own custom Control Module, you can make it as simple or complex as you need it to be. Allan

Thanks for your replies. I thought that there was a solution in there somewhere by using 2 policies that could work against each other in see-saw fashion. Thomas your method looks to be a more elegant solution so will give that a try thanks. Allan I will advise that this is outside the scope of MSP and that an application might still be the way to go. Maybe we could look to add this functionality in version 5  :

While what Thomas describes WILL work, it should NOT be recommended because it relies on behavior of MSP that is not documented or guaranteed to always work exactly as required to achieve that result.  This approach is very sensitive to lots of factors, such as device check-in frequency, and could easily get out of sync if problems occur.  When everything works right, it will behave as expected.  But we are not in a position to guarantee that this kind of solution will perform reliably over time at scale.  So, I would not recommend a customer to deploy such a solution. My point was that it my opinion it really is not a good idea for a perioidic reboot to be driven from the server.  First, it would seem reasonable to want devices to reboot on the same schedule even if they go for periods without being able to contact the server.  A solution that is based on Policies sending Jobs certainly could not work in that envionment.  Second, flip/flopping Jobs puts a continuous load on the MSP Server and Policy Engine and would be a poor choice at scale.  Performing reboot autonomously on the device makes far better sense, in my opinion, because it makes the devices responsible for rebooting themselves, once the MSP Server has configured them to do so.  If devices are manageable, MSP could later reconfigure them NOT to do so, if needed, but if devices spend long periods off the network, they would continue to reboot as they were configured to do.

It looks like a GRIP to me: 1. Control module with CRON functionality 2. Setting to fill crontab Is it hard to develop? In the meanwhile, check out PocketCRON: http://appliedpda.com/downloads/details/18 (did not test myself).

Sean; Sending Jobs from MSP to devices perioidically is NOT somethat that can practically be done in MSP 3.x and probably should not be attempted.  If there is a need to have a device reboot daily, it should be done on the device, not driven by the server.  This probably could be done without coding by using a LockAndWipe Settings with a Time or AdapterTime Condition to trigger a reboot.  The trickiest part of any such solution is likely ensuring that only ONE reboot happens per 24 hour period.  While I am sure that such a solution could be worked out, it is really stretching the intended capabilities of LockAndWipe.  It would likely be simpler and easier to just build such a feature into a custom application or just write a small application to do this very thing and deploy it with MSP. Allan

Hello Sean, this can be achieved easily with MSP. 1) Ensure the PlugIn AdapterTime is installed on the device 2) Create a AdapterTime condition "reboot" that is valid once a day between 3:00am to 4:00am. 2-a) Set "Constrain time of day" to "Constrain based on time of day". 2-b) Set "Start hour" to "03". 2-c) Set "Start minute" to "00". 2-d) Set "End hour" to "04". 2-e) Set "End minute" to "00" 2-f) Set "Set Frequency limit" to "Set frequency limit". 2-g) Set "Select frequency limit" to "Every one day" 3) Create a dummy package "reboot.dummy" to deploy something like a 2 byte big txt file etc. 4) Create a bundle "reboot1" that first install "reboot.dummy" and second reboot warm. 5) Create a bundle "reboot2" that first uninstall "reboot.dummy" and second reboot warm. 6) Create a policy "reboot1" that contains the bundle "reboot1" and the readyness condition "reboot". 7) Create a policy "reboot2" that contains the bundle "reboot2" and the readyness condition "reboot". This is an very easy and configurable approach to regular reboot devices. You have just to ensure that the devices are not suspended and able to check in during the time frame specified in AdapterTime condition. To enable the MSPA to wakeup a device if suspended just use the setting in the Agent 30 settings class. Hope that helps Thomas