1 of 1 people found this helpful
You could create a scheduled task that really is a small script that creates a local scheduled task on the machines. The local scheduler has many more scheduling options. You will then be able to query the inventory to see if the LST exists, etc...
I agree that the scheduling options are a little limited. The arguments I think revolve around whether to do this on the core or on the workstation. I would put in an ER and see where it goes, as it is a good suggestion. I would also like to have an option in your er to either have local or core scheduling of the task.
Thanks for replying Zman. I think the problem I have with using the Windows local scheduler is two-fold. Before posting I had mentioned it to one of my directors and I got the dumbfounded look of ‘why did we pay so much money for this software and it not come with a robust scheduler’. His perspective is one of dealing with many different internal groups that use products like Nimsoft, Tidal, Kintana, etc., which do this out-of-the-box. So being the owner of Landesk… now I look like a schmo because I can’t do simple scheduling to fit the needs of the business. His reply back to me when I mentioned possibly using a local Windows tasks was less than supportive… something along the lines of using a scheduler outside of the expensive software to do a simple execution would not pass audits… ‘that is what we pay the expensive piece of software to do’.
Second… trying to maintain Windows local scheduled tasks doesn’t scale well. If we were talking about a relatively simple task on handful of machines, or a minimal number of maintenance windows, I’d be more responsive to the idea. However, since we’re talking about critical revenue producing infrastructure on a scale of thousands of machines with 50+ different maintenance windows and hundreds of tasks... that is a nightmare. If a local Windows scheduled task failed… how would I know? From an auditing perspective how do I keep track of those tasks if someone were too accidently or even purposely delete them? How would we tell the difference between our critical local tasks and ones created by a user? What account would the task run as? And a whole host of other questions.
In my mind, as you’ve suggested, I’ve created this architecture using the local Windows scheduler and how it would work. Using such things like the Landesk SDK with LPM would be one way. Or I could use the neato monitoring in v9 to help keep track of it on each machine in coordination with some fancy queries and policy tasks… and then do scripting for DACLs on the task in Win2k3, or modify permissions on tasks if its Win2k8. I could make XML of Win2k8 tasks and using scripts to modify on the fly to customize, modify and import tasks. This is all doable… but it would be a horribly over-architected solution for something as simple as updating the resource DLLs in the console so that when I click on the ‘repeat’ check box the combo box would have more than just ‘hour-day-week-month’.
Wow… and now I realized I’ve rambled for too long. Btw, I’m not attacking you or your idea, as they are both valid. Just frustrated with having such a powerful tool that does much, but I seem to keep getting bit by lack of foresight on LANDesk’s part… or they’re behind the curve compared to their competition. This seems to happen at the most impromptu times too! We’re due for a true-up next month and now and rumblings are starting again. Looks like Alitiris or SCOM might be in my future!
I think I’ll go file that ER now… and pray for some luck!
I never recommended using the Windows Scheduler, but the LANDesk Local Scheduler. You can monitor the LANDesk Local Schedule Task via the LANDesk inventory or custom vulnerabilities. This will ensure that the tasks are always installed. It scales well as we use a custom vulnerability to create and install LSTs on many thousands of machines, and is very easy to create and maintain.
Ahhhh... my apologies. I assumed you meant the Windows scheduler because of the scheduling requirements for our business processes I mentioned. The local scheduler has the same limitations that the console task scheduler has, namely the lack in flexibility and the more robust scheduling options.
The other caveat is the business processes which are designed to flow from external database/source and feed into Landesk. Some of this gets into many-to-one versus one-to-many type of methodologies, but in our production and/or revunue impacting environment pull/policy based type delivery is expressly prohibited and not enabled on the client configuration... therefore the flow comes from the 'source of truth' to Landesk and is supposed to be distributed based on the schedule handed off to Landesk or pre-setup in Landesk.
This would be sooooooooooooo easy if the scheduler had what most system management tools have today! Now I'm writing code using the both the SDK and DotNet along with creating workflows in LPM to compensate for the lack of this simple feature. For some processes I'll use the before mentioned tools like Kitana or Tidal to handle scheduling. For other stuff I'm going to be storing this information in an intermediary database and using the scheduling options of SQL (which have the robust options I need) to feed into Landesk. At this point each task will be created on the fly and deleted by a garbage routine later... and with the reoccurences I need being handled external to Landesk... which is dumb.
Btw, I'm still ranting because I'm hoping someone from Landesk is watching and will take pity on me... send me some undocumented feature or beta code. Rather than continue building the above I'd be so much happier if this were built into the console... code bloat is an accruing technology debt and I hate having to do it when I shouldn't need to.
In case anyone else is reading and agreeing with me... go to http://community.landesk.com/support/ideas/1488 and vote that mutha up!!! For the sake of all things good and peaceful in the world of technology... DO IT!