1 of 1 people found this helpful
Looks like the best way to me is indeed to go for Local Scheduler. Most times when you can't rely on being able to have the clients be reachabel to do something, local scheduler often ends up being the best way ahead.
Depending on how big the package is, you may want to pre-cache it up-front on your devices, but that's about it. For the particular use-case you have, certainly seems like local scheduler is a good way to go.
If you want to be particularly fancy, you can even try to incorporate some logic into things.
- Run the job from the Core (with WOL) at 5 pm
- Run a local scheduler task at 6 pm, which launches a script to check whether the new package is installed. If not, the local scheduler will install it. If yes, it will do nothing.
Something like that, depends on how sophisticated you want things to be and how much status feedback you want/need.
LANDesk EMEA Technical Lead.
Thanks for the Info Paul,
WOL is not an option as all of the effected machines are laptops on wireless and most of them wont be onsite when we make the change.
How does one normally go about sending out a package w/o launching it (pre-cache)?
Do you happen to know off hand what the schedulers behavior is if it missed it's mark due to a machine being in Stand-by or Powered down?
Well - there's two ways.
1 - You configure a "Target Multicast (Cache only)" delivery method.
2 - You configure a delivery method as you want (even a policy), with a "dummy batch file" (which doesn't do anything, other than acting as a primary package), and hook the files you ACTUALLY want as "additional files" to that package .
Re: - Local scheduler - it depends on how its configured. If it's configured to run in a certain time frame (i.e. - between 20:00 and 22:00) it won't try to run the task. If it's just set to run daily, it will try to run the task as soon as it can, pretty much.
Hope this helps.
LANDesk EMEA Technical Lead
Thanks for the help.