I need to run QTP scripts when I'm not at work. So I'm scheduling (with windows task scheduler), batch files (which calls .vbs files) to call the QTP codes.
They run fine, if the computer is no locked (I have tried with the scheduled taks, and running the .batch directly also).
Even when the computer has been locked for a hour, the QTP scripst run fine.
But if the computer is locked for several hours (for example, if I leave work at 5 pm, and I need to run the scripts after 12 am), the QTP scripts don´t run (neither an error message is popped up, nor QTP in encycled, nor nothing).
Anybody has an idea what need to be done to work this out?
Directly from UFT help file, same applies to QTP:
When running UFT tests or components on a local machine, if the computer on which the application is being tested is locked, your test run may fail.
Workaround:
Install UFT on a virtual machine (without a screen saver or lock password), and start or schedule your run session on the virtual machine. Then you can lock your local computer without locking the virtual machine.
Another workaround (not recommended):
Play any video in loop in Windows Media Player. This will prevent your machine from get locked automatically.
In this scenario you can auto schedule the script through the external free software like Auto-Sys.
There you can create jobs to unlock the machine and then run the regression.
You can simple use the below utility to keep you system unlocked
https://sumeetkushwah.com/2015/11/07/windows-lock-prevention-utility/
use the below code and save this as a .vbs file(SomeName.vbs)
Set WshShell = WScript.CreateObject("WScript.Shell")
Do
WshShell.SendKeys "{CAPSLOCK}"
WScript.sleep (1000) '1000 means one second. choose the time of your liking
WshShell.SendKeys "{NUMLOCK}"
Loop
Double click the saved vbs file. Your computer will not get locked unless you manually kill the WScript.exe task in your task manager. Use the keys of your choice from here http://www.pctools.com/guides/scripting/detail/149/?act=reference
Related
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"
I am struggling to make a Task Scheduler task successfully runs a batch file which contains a vmrun command to start a VM. I am using VMware Workstation 12.5 in a Win 7 x64 (unfortunaltely I cannot test in others). I already had searched on other websites (including stackoverflow) and tried different approaches but I really do not understand what is going on with this simple command.
The command I am using to start the VM is this:
vmrun start "C:\Virtual Machines\Windows7x64\Windows7x64.vmx"
What I did so far:
run it in the command line to make sure it is working
created a batch file with the command above and run (through command line and double-clicking on it) to make sure it is working
created a task in Task Scheduler pointing to the bat file, configured with high privileges, run whether user is logged on or not
when I run the task (manually or waiting for the schedule time) I can see that the task starts running, although the VM is not started ever, and after just more than 1 minute, the task is finished with Last Run Result 0x0 (which means it succeeded through this link: https://msdn.microsoft.com/en-us/library/windows/desktop/aa383604(v=vs.85).aspx)
I tried the same approach using the command to stop the VM and it works!
vmrun stop "C:\Virtual Machines\Windows7x64\Windows7x64.vmx" soft
Anything I am missing here? Same command runs through command line and running the batch file, although not from Task Scheduler. Any hints, please? Any details I am loosing to look at?
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.
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.
I use Jenkins to run our builds. What I want to do is to wakeup the monitor before build starts. This is what I have done so far.
Use nircmdc.exe (http://www.nirsoft.net/utils/nircmd.html) and prepare a batch file to turn on monitor. I have tested the script through command prompt and it works fine.
Then I add a build step in Jenkins to execute windows batch file before running the ANT script. Then I remote start the build (via URL). Console shows that the batch file is being executed. But the monitors doesn't wake up.
Then I included a target in ANT to execute the same batch file and tested running the ANT via CMD. This wakes up the monitor and continue with the build steps.
But, if I run this ant script from Jenkins, everything works fine except waking up the monitor.
Is this something to do with privileges ?
Has someone done something similar?
Don't think I've ever heard of a requirement to wake up the monitor, so probably no one has done anything like this.
However, your problem is probably due to Jenkins process running in a separate session from your machine's console. Have a look at my answer here: Open Excel on Jenkins CI, it explains how to get around the session issue.