This use case doesn't make sense to me. That doesn't mean it is invalid, it just means I don't understand it.
You want to have software install on machines and the task to constantly run but track who has it installed and who doesnt...Why does a Policy delivery method not work for you? That is exactly what it is and does.
ok, I see what you mean. So let me specify what I mean.
The feature that I want is a function which takes care about the packages I've distributed. For example I want to deploy the version 9.1.2 of Acrobat Reader and don't want to let the user to update to 9.1.3. When this happens "LANDesk" (I think the Agent) should start the package that installs again the 9.1.2 version.
You say that the feature that I want is within the policy delivery method. Do you mean the settings "Type and frequency of policy" so that an above described error can be correced each day/week/month? Is this the policy? And what is checked so the agent can be sure that there was an "unauthorized" update?
If so why can you also set this in shedulded tasks (Repeat every: hour/day/week/month)? Isn't this redundancy? Or does this "repeating" do something different?
ps: I know that an update for a software shouldn't be possible for the users, but some have admin rights here, so I have to think about this problem.
Thanks in advance
I see your use case now.
You want users to remain at Adobe 9.1.2 and if they install 9.1.3, you want to uninstall 9.1.3 and reinstall 9.1.2.
So if you use a Policy and set it to required once, then when you first install 9.1.2, it is going to mark you as having installed it once and probably won't reinstall it.
If you do a push, then we will reinstall Adobe 9.1.2 on every device in the task becuase the primary package is Adobe.
So detection is the key, however, the problem is that Detection only works for a dependent package, not a primary package.
So do this (It is called the blank batch file trick (I sent this out as a "Tip and Trick" way back when 8.5 first came out)
1. Create a blank batch file.
2. Create a Package to push the blank batch file.
3. Make your Adobe 9.1.2 package public.
4. COnfigure the blank batch file to depend on Adobe 9.1.2.
5. Configure detection on the Adobe 9.1.2 package so that it fails detection if Adobe is either not there or if it is a newer version.
6. Create a Push task to push the blank batch file.
7. Have the task repeat.
Now, everyone will still run the task daily, but those who are at Adobe 9.1.2 will only rerun a blank batch file, which takes almost no resources and always succeeds because a blank batch file can't really fail to run. Because the blank batch file is the primary package and Adobe 9.1.2 is the dependent, dependent packages only run if they are not detected. It is KEY that you make it NOT detect if they have a newer version.
I hope that works for you.