I would suggest sharing the reasoning for this need right away, to see if others might have a different solution to the problem. The issue being that LANDesk doesn't really have anything to handle performing a package install explicitly at startup. I'm sure with some clever manipulation, one could get it to work, but its not inherent in the UI of the product. Not even local scheduler offers a trigger point for startup. It really only address logon, logoff, lock, unlock, startscreensaver, and stopscreensaver events as triggers, besides IP address change. None of that is probably going to work, otherwise you could theoretically use local scheduler to execute an installation, provided all the files are on the system for the install, and the command line arguments don't get to hairy. Within software distribution settings there is really only stuff for deferral, and the user logoff, but some of these things are being deprecated out. So the simple answer to your question is mostly no.
This might be a bit wonky, but I would suggest you consider a provisioning task, if you can live with push only. Unless they've changed it, there's not a way to run a provisioning task as a policy, but if you can suffer a push only distribution, then provisioning tasks could basically do what you want, as your first command in the task could be to simply reboot the machine, the next step to install your package. This would be as close to startup as you could get. It wouldn't be exactly at startup, but it would be very near it. Then after that, you could have another reboot, or any other chain of events that you want. The only challenge being that your user will not necessarily know what is going on during all of these steps unless you come up with some clever way to give the user some feedback (one example, using autoadmin logon registry values to get the system to automatically logon as a specific admin account, and perhaps produce some kind of text visible in the screen that tells the user that something is happening - a bit of a hack here, good for OS provisioning, but maybe not so great for general packages). Otherwise, the user might well attempt to log on even though your provisioning task is still under way. They would see an interface for the provisioning process though, if they did log on while it was still running, however any reboot commands that you incorporate would take effect without much that the user could do, and only a timer as a warning in that particular provisioning action.
Really you're RunOnce key theory might not be too far off. You could create a basic dos batch package that "installs" registry information for a local GPO startup script, that simply calls that same batch script wherever it is, but pass a parameter in that would indicate that it is running from there. This is a bit of a hack, but it would probably work alright. Your script would have to remove itself upon completion obviously.
Bottom line, where there's a will... It can be pulled off one way or another, but it will probably escape just a simple UI button click to achieve it. First step, apply grease to elbow!
Hope this was at least slightly informative.
There are some installs that are not immediately critical, but seem to fail due to some service still running or some other conflict with another windows process. I have seen one particular install issue that is critical (antiVirus) where the SEP update installs then uninstalls immediately after installing, causing the pc to be left with no antivirus. THis has happened on 30 or so pc's in my environment.
Rather than prompting the user for the updates & relying on them to "defer until next login", I'd rather have it done silently (or with a status bar in some cases) before windows starts, but prior to all other windows files being loaded.
In non-critical cases, I don't want to necessarily force a restart, but give users a wide range of time for that particular restart & install option, separate from my agent setting which is at a 7 hour limit. In critical cases like AV, I'd like to shorten this to a couple of hours max, with a prompt or window to show that it is installing. In particular the AV set as a runonce takes a long time to process & just shows a blank desktop, so to the end user, the pc is seemingly frozen. They will often hard-power down the laptop thinking there is an issue & the AV does not get installed.
It should be fine at login, as long as it runs like the RunOnce key prior to the other services that are starting. I'd prefer some to run similar to the way Windows Updates pops up with that "Configuring Windows" text just prior to the login window showing up. Still, the key remains that it needs to be run as System or a local pc admin account & not as the user logging in.
I found this in the ideas section but it was marked as archived...
based on the responses, it seems this may not be possible at the present time. Hoping it will get on the radar again - it seems to have gotten a good number of votes along the way.
Yes, but what I am looking to do is keep it completely silent. In some of these cases, I don't need to interrupt the end user for these installs or ask them to defer anything, In addition, running at logon is not going to help in the case of my AV issue, since it requires a restart first, hence running at startup, or after a restart at login. Not simply at next login...