Running BAT via Scheduled Task at User Logon
I've scheduled a task that run's a BAT file from a UNC path.
Path = \\wisdomserver\deployment\
Right now this is what the BAT file is:
The trigger in Task Scheduler is "at log on of any user." And when a user logs onto the machine, it seems to run, but generates a result of 0x1. I think it's failing to run as it never stops at the pause.
If I right-click on the task and run, it does exactly what it's supposed to do.
I do see something flicker on the screen when I log in, but I don't see anything in the history. The history tab actually says "disabled."
My Google Foo is not working tonight and I'm not sure how to move forward. If the task is successfully running, why isn't it stopping at the "pause?"
I suppose I could write a simple copy file routine and test things that way, but I'm sick and out of time for today, so I thought I'd see what you all have to suggest here.
Please advise!
Path = \\wisdomserver\deployment\
Right now this is what the BAT file is:
Echo is this running?
pauseThe trigger in Task Scheduler is "at log on of any user." And when a user logs onto the machine, it seems to run, but generates a result of 0x1. I think it's failing to run as it never stops at the pause.
If I right-click on the task and run, it does exactly what it's supposed to do.
I do see something flicker on the screen when I log in, but I don't see anything in the history. The history tab actually says "disabled."
My Google Foo is not working tonight and I'm not sure how to move forward. If the task is successfully running, why isn't it stopping at the "pause?"
I suppose I could write a simple copy file routine and test things that way, but I'm sick and out of time for today, so I thought I'd see what you all have to suggest here.
Please advise!
ASKER
These are non-domain controlled computers that need access to a computer that's hosting some files. Eventually, they will all be joined to the domain, but that's in the future. Right now they're just getting some pre-config work done.
i am unsure "pause" does anything in a non-interactive environment
afaik, ( and guess ) the unc path probably works, the batch probably runs in it's own window but not attached to a desktop, and probably works.
it would be easier to test by logging a line, creating a file just for reference, starting a useless service, creating a dummy route... well something else than a print.
also note that "sleep 5" should work in non interactive scripts which would also allow you to test quite easily
afaik, ( and guess ) the unc path probably works, the batch probably runs in it's own window but not attached to a desktop, and probably works.
it would be easier to test by logging a line, creating a file just for reference, starting a useless service, creating a dummy route... well something else than a print.
also note that "sleep 5" should work in non interactive scripts which would also allow you to test quite easily
- You get a window only if the task user is the same as the interactive user logging in, and the task is set up to "only run when logged in".
- If you do not see a window, pause stops the script without any way to continue (you cannot press a key)
- To have a task history, you need to enable it (for all tasks). Right-click on a task, and you should be able to see a corresponding menu entry. Don't forget to disable it again after having finished troubleshooting, otherwise you'll get a lot of unnecessary logging.
- A return code different from 0 for a task usually means an error returned from (one of) the task's action script(s). But to make sure the task scheduler itself does not have issues, enable history as shown above.
echo Something >> c:\temp\batch.log
Since this is temporary until you get into the domain, can you just join to the domain now? Does the domain exist?
If it were me, I wouldn't want to spend any time trying to get a workgroup working if it were possible to go to a domain. All work on a workgroup is "wasted", and the time would be much more effectively spent setting up group policies and such that do the joj much more easily and effectively.
If it were me, I wouldn't want to spend any time trying to get a workgroup working if it were possible to go to a domain. All work on a workgroup is "wasted", and the time would be much more effectively spent setting up group policies and such that do the joj much more easily and effectively.
Hmm.. i quite disagree with the above : domains have a reason to exist when you run lots of machines, need to distribute apps, access to resources, provide ssos, and are prepared to use gpos and other complex tools, need roaming users...
On the other hand, running a domain for 6 machines in a single location will be much more error prone, require lots of resources to maintain redundant domain controllers, allow easier global infections, require more time, prevent you from switching to non windows desktops...
Going the domain way is not always the better solution
On the other hand, running a domain for 6 machines in a single location will be much more error prone, require lots of resources to maintain redundant domain controllers, allow easier global infections, require more time, prevent you from switching to non windows desktops...
Going the domain way is not always the better solution
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Of course, if all of this is to do what you would normally do in a domain, a domain seems like a good way to go. ;-)
ASKER
Using the Windows Windows 10 Startup folder is what I ended up doing here.
For those of you insisting that I join the domain, if I could I would, but that's not an option for these particular machines. Sigh...
Ha!
Thank you all for weighing in.
For those of you insisting that I join the domain, if I could I would, but that's not an option for these particular machines. Sigh...
Ha!
Thank you all for weighing in.
Yep. In case you are interested, the startup folder scripts are spawned after the logon at the same time as both other startup scripts and the user's shell and hence as whatever the user decides to run manually. And they are executed in the user's session allowing the user to interact with them. Including kill them before completion.
Most other ways to spawn startup scripts will produce non interactive processes that will run sequentialy before the user can use his or her desktop.
Most other ways to spawn startup scripts will produce non interactive processes that will run sequentialy before the user can use his or her desktop.
FWIW, the path above is wrong and needs to be
%ProgramFiles%\Microsoft\Windows\Start Menu\Programs\StartUp
Or, is it? %ProgramData%\Microsoft\Wi
Either I mistyped or did not notice the autocorrection, nvit has the correct path reflected.
In a domain, this would normally be run as a login script via group policy. What is the ultimate goal of the script? Will this apply to all users, some users, all users on specific machines?