The options in a Policy based distribution give you all of the above. As a machine reports in to LANDesk and looks for policies, it applies the policies it has not successfully applied (and the distribution packages). It then "pulls" the the distribution package and installs it as per what is outlined in the both it and the Policy. "Pull" doesn't mean to say that the agent will always download the distribution task because it has Policy based distribution (more like a request to have it installed), but rather it's not a "Push" from the LANDesk server such as using a scripted task.
As for targetting, when a scheduled task runs, it also executes any associated queries/groups/etc. and populates its targets accordingly; unless it has been manually populated in which case it has nothing to query against.
Thanks a lot for the reply, Jmac.
So, which option (from the below given) should I select in the "Schedule task" page in the Scheduled task properties window?
1. Leave unscheduled (do not reschedule task)
2. Start now
3. Start later
Date & Time
 Repeat every Hour/Day/Week
 Deploy packages in this task even if they were previously deployed.
My requirement is to trigger the task on
1. All online machines which are part of mentioned AD group
2. All offline machines which are part of the mentioned AD group (as soon as they come online)
3. All machines which are going to be added in future
To add more to the 3rd question, how much time will it take to trigger a job if I add a computer to the AD group now? I should not be triggering the task again to schedule it on the newly added machine.
LANDesk should check for the targetted AD group/query, trigger the job on the failed machines, trigger the job on the newly added machines and most importantly, it shouldn't trigger the job on the successful macines.
Message was edited by: Chetan Kumar Tammala
The Start options give you the ability to chose when the scheduled task will actually start working. Once it is started, the scheduling service will periodically start the task again so that it remains up to date. But remember, with a policy based distribution, the agent checks with the server and then pulls the distribution package (or whatever is associated with the scheduled task). So the start time is really not that critical so much because its the agent that will actually kick things off.
The repeat options are probably not required if you are just distributing software. You might use the repeat if you were deploying something like an anti-virus definition where you want the targeted machines to periodically check in for updates. Don't select this if you want the job to just run once.
The "Deploy packages in this task even if they were previously deployed" is sometimes available and sometimes not. I use this feature when testing software packages where I want the install to run again even if it had already run once. Its also good to use if you are deploying updates that might end up needing to be run over a few times to get them completed. Note: this option can't be changed after the scheduled task has been started.
Each time a scheduled task starts, it updates all of its associated queries. The default for the scheduler service is 1hr but that can be tweaked in the services/scheduler tab. Be careful when playing with this time because you don't want to over load the server. You can also create the same effect by right clicking on the scheduled task and select start now.
With a policy based distribution, you can set the options if you want the distribution package to be available all the time or run just once. Compare the policy delivery methods "Always listed for installation" and "Required installation" to see the difference. With a policy, its the agent that decides if it should, has or has not run a package.
Thanks a ton for your time in answering my questions in detail. I really appreciate it.
I will do the below test case and let you know the results.
1. Create a schedule task (to distribute an MSI package)
2. Target it to an LDAP group which has 3 computers
3. Start the schedule task now
4. Verify the package installation on the 3 computers which are part of the targetted LDAP group
5. Now I will add 3 more computers to the same LDAP group which is in Active Directory
6. Wait for 1 hour and see if that task will trigger on the newly added 3 computers or not
I did the below mentioned test case; please find the details below.
1. Created a schedule task (to distribute an MSI package)
2. Targeted it on an LDAP group which had 2 computers
3. Started the schedule task by clicking on "Start now"
4. Observed that the package installation was successful on the 2 computers which are part of the targetted LDAP group
5. Now I added 2 more computers to the same LDAP group
6. Wait for 1 hour and observed that the task got triggered on the 2 newly added computers.
7. I did something to get the task failed on one machine and this machine is shown in the failed section of the task on the core server
8. I waited for a couple of hours, but the task didn't get triggered on the failed machine again
9. I even tried triggering the policy.sync.exe on the failed machine, but no luck.
Can you please let me know if this is the expected behavior. If yes, how to trigger the task again on the failed machines?
No problem, glad I could help. Good to see that you are well on your way to getting this going.
For the machine(s) that failed, you may need to perform a software inventory for them to report in that they need the task to run again. At least, from what I have discovered, after running an inventory (from the agent or the script from the server) followed by the scheduled task running on its interval (server side scheduler service) and a policy sync (agent side), the task will or will be available to run again. I know this doesn't make a lot of sense because you can see the machine failed in the scheduled task. My guess, mainly because I never really bothered to confirm it 100%, is that the record of the failed/success of the software install is included with the software inventory. The agent stores a record of all of the distribution packages that it ran (successfull or not) in a local database (LDClientDB.db3) located in "C:\Documents and Settings\All Users\Application Data\LANDesk\ManagementSuite\Database". I would assume that the contents of this database is included with an inventory when it is run. The database stores the ID of the distribution package (not the scheduled task) and marks it as successful or failed. Deleting this database will cause ALL policies to run again regardless if they were successful or not, but only do this as a troubleshooting step. Recreating the distribution package will generate a new ID and will cause the same effect but only for the 1 distribution package. If you delete a distribution package, you must also delete its associated scheduled task(s) first.