This is doable, however depending on how many agents you have and how much horse power your core has and how many tasks you have set up, you may run into some performance issues if you get a lot of this sort of activity going on. Consider carefully if you will be doing on demand vs. required policies. If its only the former, you'll probably be fine, but if you attempt the latter, you might get a huge snowball going against your core. Just depends on how many instances you think you may get at any particular interval of time. At any rate the way to do this is to run the inventory scanner with the proper command line switches. You're going to have to use the /F switch to get the software to update guaranteed, otherwise it might skip the "software" scan since you have your settings at 2 days. You won't be able to know for sure that it will perform the software scan each time on demand, unless you use that switch. You might even need to use /SYNC switch, but hopefully you'll get away with just the /F switch. The /SYNC will get it for sure, but it makes for a heavy load for the inventory scanner, and will put a drag on your core if you have a lot of devices doing this at any given interval, so be mindful of this, and plya it by ear.
You'll need other switches too, so study this document: http://community.landesk.com/support/docs/DOC-1499. You can take a look at how your agents are already configured by looking at the local scheduler tasks. You can do this by either looking in the LocalSch.log file in the LDclient folder on the agent, or you could also get an output in a command console by executing: "C:\Program Files\LANDesk\LDcient\LocalSch.exe" /tasks | more
That's assuming your agent is installed in the default location on devices. This is XP of course. For the newer OS, it should be under the Program Files (x86) folder. At any rate, You might also look under "Manage scripts" in the console, and look for an "inventory scan" job in there. There should be one. You can choose "edit" on this script, and then take a look at how the code is set up for LDISCN32.EXE
You'll need to perform the inventory scan after your distribution package, so depending on how you've built this package will decide the best approach for chaining in the inventory scan. You can chain up to three packages in a package. a Before, the main, and then an after package, so you should be able to pull it off this way as an after, or if you're constructing simple batch packages, you should be able to just add the inventory scan into your batch file.
Things to consider... Sometimes inventory scans get stuck. This will make your package also get stuck. You might want to figure out how to use a batch with a "Start" command (without a wait - review the command line options for start to get this to work right), so that the start command can spawn the inventory scanner in a separate process that will break free from the main process, allowing the main process to wrap up and get done, and not hang up the task, so this way the core will get back the status info from the job rather than take a chance with a sticky inventory scan. Its rare, but it does happen. Also, even though the inventory scan occurs on the agent, there's still the matter of the refresh time on the core for all your tasks. If you have a lot of them, the longer its going to take for them to all refresh. There's a time interval for how often the tasks get refreshed, so you may have to play with that to get it to go as fast as you want it to get refreshed, but remember that its going to have a point where it just won't refresh any faster than as fast as it will go through all of them. This might take 20-30 minutes minimum, and until the specific job refreshes, after receiving the updated inventory scanner information from a given device, that device will still show that task in its list. Once the task refreshes, then it should disappear from the task.
There's another approach that you might consider instead, but it might be a bit much to cover here or too confusing. We use custom definitions to build our packages. We then use a sort of stock generic batch file that we pass variable parameters into to drive a security scan repair for a specific custom definition patch. This batch file is the "package", but the custom defintion that the package calls is the real payload, which is handled by security scan - Vulscan.exe. The one neat thing with this approach is that once a Patch is "repaired", provided that the detection logic is set up properly, once the patch goes to a "not detected" state, it will not attempt to install again, even if an operator attempts to execute the policy again and again. They simply get a "NO PATCHES AVAILABLE" error, since its already been satisfied. In this scenario, the policies always show up in the list, but they just wont do anything more once they have been successfully used once.
Anyways, hope this helps get ya in the right direction. Good luck.