Offline KScript not running at user login
When I set this script to not run on a schedule, but to run at user login, the script never seems to run (no matter how many times I reload inventory, log off/on, restart, etc). However, if I point the script to one computer and click "Run Now", it works perfectly.
I saw some people complaining that "Also Run at User Login" was not consistent, and some people were theorizing that the script was making changes to a system account and not the user who logged in. Am I missing something?
Thanks!
~Mark
Answers (4)
Hello!
I am on appliance v5.3.53053 and I am also experiancing the same issue. I tested it on clients with agent version 5.3.53177. It will run on "run now" but not during logon. Could it be because I already ran it on the targeted machine once with the Run Now option? If so, is there a way to reset script attempts so it'll run again at login?
~awingren
Comments:
-
I just tested it again with a fresh client on 5.3.53177 and it worked. I really think the issue (for me anyway) is the script ran once and doesn't want to run again. - awingren 12 years ago
I ran into a similar issue. My theory is that the script is running before the user is logged in enough to access the registry. I haven't tried it, but what if you put a delay in the script to give the profile a chance to finish loading?
I ended up with a combination of group policy and a scheduled kscript to push our IE settings, but if I have a minute, I'll try on login again.
Casey
I know this is an old thread, but, it is what I was searching for and have now since figured out in client 5.3.53177 server 5.3.53053. I too had issues wanting to run a script prior to login or at boot. I'm settling with at boot for now because it accomplishes what I need; removing user issues.
Seems the problem is with an offline script is options of 'Also run at...' when it is acting like it needs to be a radio button choice rather a this or that check-box.
So I have my script that is not run on a schedule, and only one item checked; Also Run at Machine Boot Up. The only issue I see using this, is it seems to take a couple boots before it stops checking for scripts at boot up.
so that the conversation will remain readable.