scheduled tasks don't stick when baseline is reset?

I’m experimenting with CMT for use on kiosk stations in a public library setting. We’d want to be able to script things like software version updates to happen overnight, followed by taking a new baseline snapshot and having a scheduled task restore the machine to that baseline upon every reboot.

However, when I use the Reset Baseline function, the scheduled task for restoring at every reboot simply disappears. This is kind of a show stopper, since the command line interface doesn’t seem to support creating the scheduled task again. This means updates cannot be completely automated. If it’s not automatic, it’s not viable here (ultimately, this has to work on 500+ machines).

Any advice? Any hope that a future version will support creation of scheduled tasks via the CLI? Wait for the Enterprise control module? Thanks.

To compact the snapshots
\Comodo Time Machine\ctmcmd.exe /D

To restore your system to the Baseline snapshot
\Comodo Time Machine\ctmcmd.exe /r /baseline /user “username” /pass “password”

To restore your system to the latest snapshot
\Comodo Time Machine\ctmcmd.exe /r /current /user “username” /pass “password”

To restore your system to the snapshot closest to a certain time
\Comodo Time Machine\ctmcmd.exe /r /time “<date & time>” /user “username” /pass “password”

To take a snapshot
\Comodo Time Machine\ctmcmd.exe /n /name “name of the snapshot” /comment “description for the snapshot” /user “username” /pass “password”

Note: The date has to be specified in yyyy-mm-dd format and the time has to be specified in 24 hr format.
Note: The Username and the Password are required only if Access Control is enabled in User Settings area of Settings interface.

when I use the Reset Baseline function, the scheduled task for restoring at every reboot simply disappears.
Yes , it is a correct logic. Think about in the following scenario: Take a new snapshot that named "AAA", and add a scheduled task for restore to snapshot "AAA", then reset baseline. The snapshot "AAA" has been deleted, so the restore task is invalid now.
his is kind of a show stopper, since the command line interface doesn't seem to support creating the scheduled task again.
Yes, the command line interface of CTM doesn't support creating scheduled task, but support take snapshot, restore system and reset baseline. So you can create several related scripts that can reach your goals.

It might be possible to use these variants in a script that would be triggered as a Windows shutdown task via Group Policy. Thank you. I will test it out.

You’re welcome gbarniskis.
Please, post back your results :slight_smile:

I assumed it was something like that. The task’s pointer to the old snapshot gets destroyed with the snapshot.

However, let me suggest that in a future version you do make “restore Baseline on reboot” into a CTM “configuration feature” (a check box somewhere in Settings) instead of a scheduled task that is subject to being broken. At system startup, CTM could check that Setting and if it is marked then do a restore to the current Baseline no matter when that was created or what it is named. My point is that even though the current behavior can be worked around via external scripting and external scheduling, doing “restore on reboot” really should be an internal core function of the product that isn’t broken by normal use of the product. It should be able to stand alone without external scripts.

I am modifying this post to retract my suggestion that CTM behavior be changed in this regard. After doing some thought experiments regarding our overnight maintenance schedule, it seems like using an external script to control CTM restore actions is not only viable, it is the only solution that will work and we would never want CTM to be in a state of “always roll back on every reboot”.

With an external script we can conditionally determine if a rollback is appropriate or not appropriate, with the primary determination being the time of day: during business hours, do a rollback, but don’t do a rollback during the overnight maintenance window (where perhaps we are installing things that require a reboot in order for the update to succeed).