You cannot make a Scheduled Task happen at every login, but you can make the Agent's own Local Scheduler run a command that is triggered by a user logon. What is your scenario?
Well, I have quite a few things I'd like to do at every login, but one example off the top of my head is to map a drive (non-persistently). We have an app that requires a mapped drive that they do not want to be persistent (for some reason). Previously they were using Novell ZenWorks to map the drive at every login, but now we have replaced Novell with LANDesk and they want the same functionality. Using a login script is the obvious solution, but since our Login scripts are managed by another team which does not quickly respond to changes, they want the function to reside with my team using LANDesk.
Take a look under "Manage Scripts". This is under the menu "Tools", sub menu "Distribution".
When you bring up this panel, look for the sixth icon from the left on this panel. It looks like a green + symbol with a clock.
This is for "New Local Scheduler Configuration Scripts". With this you can either add or completely replace all the local scheduler items on devices, so you'll want to study this to get the hang of what all it does. From this you can easily schedule whatever you want, and you can choose "Run at login" easily. Once you save a configuration it will create a basic landesk script that you can then edit manually to see all the code and how it works.
Problem here is that Local Scheduler runs things as the LocalSystem account, whereas login scripts are typically intended to be run as the current user in order to make changes to their profile settings, map drives, My Documents, environment variables, etc. You would have to make sure everything being called by Local Scheduler goes through startasuser.exe and that the user has enough rights to do everything in the script.
That is correct. Very important detail for something like connecting network shares.
This worked fine in my lab, when I log onto the workstation I get a temporarily mapped H drive using my credentials.
The Managed Script looks like this:
[MACHINES] REMEXEC0=<qt/>%LDMS_CLIENT_DIR%\LocalSch.exe<qt/> /del /range=%quote%1001|2000%quote% REMEXEC1001=<qt/>%LDMS_CLIENT_DIR%\LocalSch.exe<qt/> /exe=%quote%C:\Program Files\LANDesk\LDClient\startasuser.exe%quote% /cmd=<qt/>///SILENT ///TIMEOUT=90 NET USE H: \\MCP\PKG /PERSISTENT:NO<qt/> /taskid=1001 /toe=logon /start=%quote%07 Sep 2011 15:07:57%quote% /user
/toe=logon means run at user logon.
/user means only run if a user is logged on.
Hi there I am actually trying to do something similar.
I need to have an EXE run every time a person first logs in to there workstation. I have the below exe that is on a network share that need to be running on a users computer. This has to run every day as the user.
The frist plan was to have the following bat fill run on the log in script from GPO. But I would like to use Landesk to do it as some yours have been end tasking the exe files.
I would like landesk to rerun the exe if it finds it not running on a users computer and run it at first log in.
Would your suggestion be the best why to go about this. Would it be just that simple? If I run this script on a workstation will it always run after that? Am I missing any steps?
You're going to have to get a good understanding of how local scheduler works. You've got a compounded problem that you're working with, considering that you're wanting to run this application from a network share, AND as I read your question carefully, I think you're also wanting some logic to do a "check" to see if the application is already running or not, and IF not then run it. If this is all true, then you have a much tougher nut to crack than just scheduling a one liner command. Plus, I don't believe you can chain a net use command to another command like i think that you're trying to do within the local scheduler like that. In fact, I think the way the entry would have to look, you'd need to put the "command" on the first line, and all the parameters on the second line.
Getting back to the real problems here... As mentioned earlier in this thread by JSMCPN, the local scheduler is a windows service that runs in the "system" account. That means it will not have access to network shares or anything on the network. The system account is limited to the local drives only. You will have to run the utility called STARTASUSER.EXE (should be in the agent folder) and have it execute perhaps a batch file that then contains all the commands that you want to happen. This way the commands will actually be in the user context and the net use command will work right, but again if you are wanting this process to check for the executable already running then you'll need to expand a little on what the batch file does. You could incorporate a tool like PSLIST (formerly sysinternals now MS), to check for a specific process running, and then act accordingly. There's probably other tools like this, but whatever tools you decide to use, ALL the files required for this work should be kept local. Number 1, for performance. Its a terrible idea to be launching EXE's over the network wire every time someone logs on to a computer if its not absolutely necessary. This creates a lot of network traffic, and its just not a good practice, if you can help it. Its always ideal to copy these files locally, and launch them there, if they'll work properly, even if that means you have a little batch script that copies them down just to keep them up to date. Ideally such a script would do a hash check on said files and bring down copies only when they are not the correct files. Very complicated to code in a batch file but doable. At a minimum you will have to have the batch script local, because again the local scheduler wont be able to reach over the wire to get to it running as system.
Bottom line, if you're dealing with network junk, you'd probably be better off to put this in a traditional logon script if you have the option to do so. If you already have one then use that instead. On the other hand, if you can accommodate putting files locally, the one advantage that i see for using local scheduler is less AD maintenance, since you're putting the configuration straight into the device. The one thing i don't like about logon scripts is that user accounts are not always tied to them. Sometimes you want something to ALWAYS happen for everyone, and then other times you want it to happen for only certain folks. logon scripts can be a way to do this, but another way is by device. I think the latter is a better fit for local scheduler method. Still another reason that local scheduler can make more sense might be a social-political circumstance. Maybe someone doesn't have the permissions to work with a logon script, or the job duties. Often times these things belong to admin folks only, and then desktop work belongs to other folks. I've thought about using this feature for some things in our environment, but i always come back to what will it need? If it needs network access, I really don't want to fool with all the extra work it takes to make it function, but if it were something simple like check something local on the computer, and then perhaps interacting with the user in some way or causing some action, or something along those lines, then maybe.
Good luck with whatever you decide!