I have a VBScript which basically calls some Informatica CLI commands. These commands will take a long time to execute and the script runs in a Windows 2003 server.
cscript //B //Nologo <script> params...
Actually, I am calling this script from a .NET Winforms application. The idea is, even when form is closed, the script continues to run. It works fine, as long as user is logged on, i.e. even when winform is closed, the script runs as a (user) process and execute the command.
The problem is however when the user logs off (or) remote system (MSTSC) times out, the (cscript) process is killed.
Is there anyway this can be run as a system process so that even when user logs off, the script continues to run?
(Please note that running the .NET EXE as a Windows service is a last option, which is currently not viable..)
Only way I know to do this is a pretty dirty hack so you should at least consider the .NET service approach... Visual Studio offers great tools which allow you to make a Windows service very easily.
What you can do if that is really not an option is using the task scheduler. As long as you do not need user interactivity you can say a task should be "Run whether a user is logged on or not". If you do this you are allowed to use "SYSTEM" as the account to run the task with. So you can create your task executing your script without any trigger, and then manually trigger the task from the program.
There is no nice way to do this from C# but you can just execute schtasks /run /tn <taskname> or do a quick google search for some of the wrappers people wrote for this. The script will run (invisibly) in the background and survive user logoff if started that way.
Related
I'm trying to run a .vbs file as a scheduled task through Windows Task Scheduler. Under the 'General' tab, when I select "Run only when user is logged on", the script executes as expected.
However, when I select "Run whether user is logged on or not", and enter the appropriate credentials, the task runs at the scheduled time, but the script does not actually run. I've already tried running the script under wscript.exe as well as cscript.exe, but no luck with either.
EDIT: Even if I am logged in when the task begins, the script will still not run under the "logged in or out" setting.
Additional info: The purpose of this scheduled task is to run before I arrive at work. I've already configured my BIOS to startup at a predetermined time (06:00), and set the Task Scheduler to run at 06:27. I've successfully tested the BIOS startup, as well as the script itself (including using the Task Scheduler to run it). Therefore, the only weak link I can find is the option to "Run whether the user is logged on or not".
I'm running Windows 7 Enterprise.
Any help would be appreciated!
This is because normally it would run the script using the shell handler, which by default is wscript.exe. When there's no desktop environment (because no-one is logged-in) it would fail and abort script execution (or rather, not run the script in the first place).
To fix this, instead of running the .vbs file directly, change it to run cscript.exe (the command-line script runtime program) with the script's filename passed as the first argument. Also be sure to ensure you don't have any InputBox or MessageBox calls (instead use WScript.Echo to return messages to the user: wscript displays message-boxes, but cscript will write it to the console.
I have a ClickOnce application that we start on Log on and recurring. After I install the application the tasks work fine, but if I reboot the machine the scripts run but they fail to start my application. I added logging to the BAT file and I know it is executed, but calling the rundll32 line produces no result and generates no errors.
If I manually run the script, from explorer, it works and task scheduler executions start working as well. Also, if I manually run the clickonce shortcut the scripts start executing from the Task Scheduler. Is there someway to verify that dfshim is loaded, or load it before executing it? What am I missing? I tried clearing the cache and that seemed to fix it on one machine, but it seems like a coincidence because it did not fix it on another machine.
VBS Script Called first(Called By Task Scheduler):
Set WshShell = WScript.CreateObject("WScript.Shell")
obj = WshShell.Run("C:\Users\brnapolitano\AppData\Roaming\FirstAmerican\TaskScheduler\AppReferenceInvoke.bat", 0)
set WshShell = Nothing
BAT Script Called Second(Called by VBS above):
rundll32.exe dfshim.dll,ShOpenVerbShortcut
C:\Users\brnapolitano\AppData\Roaming\Microsoft\Windows\Start
Menu\Programs\FastLocalService\FastLocalService.appref-ms
I would like to make this a script fix, but if that's not possible, I will try adding it to the startup and see if that resolves my issue.
I found the answer(linked below). I am still in the process of testing, but it seems to work. dfsvc needs to be run, if not active, before running the command to start the shortcut.
ClickOnce app not starting from the scheduler
It's not clear from your post what is happening after reboot. After the reboot are you trying to run the scheduled task after logon or before logon? If the latter, your vbs and bat files are most likely running under a different security context than what you think it is. That could also be the case after logon depending on the settings in your scheduled task.
See Task Scheduler is not supporting option "Run with highest Privilege" and "Run weather user is logged on or not"
My EXE is executing perfectly fine when I am executing it by double click on it, but it is not executing when I am trying to run it via Schedule Task.
I am running schedule task on a local machine as administrator. I have already set the following settings into the "Security Options" of the Schedule Task.
Run only when user is logged in (I am logged in when schedule task is running)
Run with highest privileges check box is checked
In my case, it didn't worked because of the start in location of the program.
Set the [Start in] (optional) properties of the scheduled task with the path where the exe file is exist.
The default [Start in] value is C:/Windows/System32
Depending on which Windows OS you're running this on, your EXE may have in fact started and is running in the background, with the user interface completely hidden. Depending on the EXE you are trying to run, it may be sitting there, hidden, waiting for user input that it will never get. If your EXE doesn't require any user input (something that just runs and then closes when it completes), then you might just check to see if the job is actually done.
A trick I have used to verify this is to create a small batch program like this:
#echo off
echo myEXE Scheduled Task Started %DATE% %TIME% >>c:\myEXE.log
myEXE.exe
echo myEXE Scheduled Task Completed %DATE% %TIME% >>c:\myEXE.log
Have your scheduled task call this batch script instead of myEXE directly. This will generate a text file (myEXE.log) that you can check to verify when the scheduled task kicked off, and then when (and whether) the EXE finished.
Just for kicks (and to test what I'm talking about) you can add these lines at the end of the batch script.
pause
echo Batch Script Finished %DATE% %TIME% >>c:\myEXE.log
If you never see the cmd window waiting for you to Press any key to continue... then you'll also never see the last line in your log file (myEXE.log)
Windows Task Scheduler is a strange beast of a program. It's not really a CRON like task scheduler and it's not a Quartz based program, other than relying on internal clock system.datetime, which has been known to have "issues" of its own.
Nevertheless, it can sometimes trip over itself (unproven, but from personal observations), when it comes to permissions of a task and who created it vs what account is used to run it.
I found the following steps gives me a "clean" task schedule every time, and the task runs every time:
Always run Task Scheduler as Administrator. If you don't have admin rights to do this, then you should even be here!
Don't create a Basic Task. Go straight to Create Task, and under your own admin account (doesn't have to be God Admin!).
When filling in the task wizard, don't provide a trigger UNTIL you've tested the task first. Also, make sure you've allowed the task to run whether you're logged in or not! That catches me sometimes.
Don't worry about Settings, for now. Accept the default
Save/OK
Close Task Scheduler
Restart it again, and again as Admin
Run the task you've created.
If all goes well, it ran! Do a CMD run of the EXE using #Wes's suggestion to be sure.
Now, place a Trigger of your choice
Change the Account to your proper task admin account, or a generic account with admin rights specifically created to run tasks. We call ours admin.tasks
Save everything and you should be ok from here.
How do i do this?
i've tried all i can think of.
Browsing for my .exe file i want to run.
run a bat file
writing forcedos.exe in program textbox and path to my bat file in command line parameters textbox
Why cant it just work with an normal exe?
and i know it should run a program because it can restart the service correctly.
EDIT
Application: test.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.Exception
This is my latest try to make it work.
the script has the code
Dim objShell
Set objShell = WScript.CreateObject( "WScript.Shell" )
objShell.Run("iexplore")
Set objShell = Nothing
Now the script opens internet explorer if i run the cmd command
wscript.exe "C:\asfh.vbs"
The "run a program" recovery option for when a service crashes runs the specified executable in the same way as the service, i.e., it runs in session 0 (and so is affected by session 0 isolation, see also related questions) and it runs with the same security context as the service.
This means that it can't interact directly with the user (you can display a GUI, but nobody will see it) but it also restricts what the executable or script can do. For example, some shell API functions will not work properly unless the user account has been interactively logged in at some point. In the example script you posted, the script itself is probably running, but is unable to launch Internet Explorer because IE is only designed to run in an interactive session.
Provided you restrict yourself to basic functionality, it should all work as expected. (There is no master list that I know of describing what functionality is safe to use in a service context, but it is usually easy to guess. You can resort to trial and error if necessary!)
Also note that as far as I know forcedos.exe is no longer present in modern versions of Windows. If you want to run a batch file, you can specify cmd.exe as the application and /c myscript.bat as the command line parameters.
Is it possible to run handle.exe (from sysinternals) from a service (in windows7) without having to turn off UAC?
The service is a custom c-app that needs to find out which process is locking a file it tries to access and handle.exe seems to be a good way to solve it but i can't get it to work with UAC turned on. This app runs all the time so i can't have a UAC prompt while its running but its fine if it shows up at startup.
Handle.exe works fine from an admin commandprompt but fails when trying to run from a normal prompt.
I call handle.exe from CreateProcess() and get the output from pipes. I guess there should be a way to solve this but i can't figure it out. Setting up the service to log in from an admin account does not seem to work.
UAC does not affect services (it only affects interactive sessions) so that should work.
However, if you don't want to move your entire program into a service then there are better ways to do this which don't require creating, installing and managing a separate service process in addition to your main program.
If your program requires admin rights to work at all, and this isn't the only place it will require them, then you could flag your program (via its embedded manifest resource) as requiring administrator rights. It will then trigger one UAC prompt whenever it is run and be run with full admin rights, including the ability to run Handle.exe.
On the other hand, if this is the only place where your program needs admin rights, it may make sense to create a COM DLL which wraps your Handle.exe call (or any other admin work) so that you can use UAC to make elevated calls to that function from your non-elevated app. You will then trigger a UAC prompt each time you create (an elevated version of) that COM object. You can keep the COM object open as long as you want, and create it whenever you want, so when and how often the UAC prompt(s) appear are still up to you.
Both 1 & 2 are standard uses of UAC so any good documentation or tutorial on UAC will describe how to do them in detail.
You may want to look at the Win32 API method CreateProcessWithLogonW.
There is also an elevate VBS script here you may learn from: http://technet.microsoft.com/en-us/magazine/2007.06.utilityspotlight.aspx