Check if a scheduled task is running using vbscript - windows

Is it possible to determine if a scheduled task is running on a local or remote machine using vbscript?

There's a WMI class called Win32_ScheduledJob that has some status fields that might be useful. Especially the ElapsedTime field looks like it might be what you're looking for, assuming that it gets reset when the task stops.
Here's some sample code for looking at the statuses. Just set strComputer to the name of the computer you want to look at (. means the local computer).
Otherwise, if that doesn't work, you might be able to just look at the Schedlgu.txt file in the Windows directory and see if it's started but not yet stopped.

You might be able to get this information with the command-line command schtasks /query... but you'd probably have to grep the output to find only the jobs with a status of "Running".
Details on usage can be found here.

Related

sc.exe alternative to find deactivated Windows service?

I use sc.exe to stop/start services on a remote \server in a pre/post build batch. Unfortunately sc does not seem to deliver any information about the service being deactivated or not which leads to an accumulating timeout when using the sc start command on deactivated services. Does anyone know an alternative to check the deactivated state on a remote service in the command line?
This is what you are looking for..
How to test whether a service is running from the command line
look down for the WMI/WMIC options. You will need to modify the command line slightly to attach to a remote machine.
If you need to know the start mode property, add it to the command line like this:
wmic /locale:ms_409 service where (name="RemoteRegistry") get state, StartMode /Value
This produces:
StartMode=Disabled
State=Stopped
I am not marking as duplicate because your wording and needs are a little bit different.

Discrepancy in timezone between timestamps for lastlogon using WMI commands

I'm trying to get the user's last logon in some Windows machines using WMI, but for some reason, this information is different for different commands when I think they should be the same.
The first command that I'm using is : PATH Win32_NetworkLoginProfile WHERE "Name='DOMAIN\\fakeuser'" GET LastLogon. The result for it is like below:
LastLogon
20181206093540.000000-480
The second command is: PATH Win32_NTLogEvent WHERE "(EventIdentifier =4648 OR EventIdentifier = 4647 OR EventIdentifier = 4634)" GET CategoryString, TimeGenerated, InsertionStrings
The result is like below (after some processing to find the last entry of category "Logon" linked to the "fakeuser", since the command returns a lot of information):
CategoryString
Logon
InsertionStrings
{"S-1-5-21-3457937927-2839227994-823803824-1104","DOMAIN$","DOMAIN","0x3e6","{00000000-0000-0000-0000-000000000000}","fakeuser","DOMAIN","{00000000-0000-0000-0000-000000000000}","localhost","localhost","0x64c","C:\Windows\System32\svchost.exe","999.999.99.999","0"}
TimeGenerated
20181206173540.580545-000
For what I understand for these two commands, the LastLogon in the first result should be the same of TimeGenerated in the second one. Am I misunderstood something?
In my preliminary research, I found a possible bug in the WMI Timestamps, but I don't know if it is the same problem.
Some additional information:
These commands are executed using a script that make a remote connection using WinRM connection (ports 5985 and 5986) and then executes the commands to get the info, but I also tried to connect in the machine using RDP and execute it in Powershell with wmic PATH.... The result is the same.
I tested it in Windows 10 and also in Windows Server 2012, but the scripted will be used in some other Windows versions.
To get the Event numbers for the log class, I used this link
After first comment, I noticed that the problem is in time zones. Are there any way to set timezone direct in these commands or convert timezones between them?

GetScheduledTaskInfo NextRunTime is wrong

I'm trying to use Powershell to get the NextRunTime for some scheduled tasks. I'm retrieving the values but they don't match up to what I'm seeing in the Task Scheduler Management Console.
For example, in the Task Scheduler console my "TestTask" has a Next Run Time value of "1/9/2018 12:52:30 PM". But when I do the following call in Powershell it shows "12:52:52 PM" for the NextRunTime.
Get-ScheduledTask -TaskName "TestTask" | Get-ScheduledTaskInfo
From what I've seen the seconds value is always the same value as the minutes when returned from the PowerShell Get-ScheduledTaskInfo cmdlet. I'm wondering if there's a time formatting error (hh:mm:mm instead of hh:mm:ss) in that cmdlet but I have no idea how to look for that.
The task is running at the exact time shown in the console so that makes me think that it's an issue with the powershell call.
Has anyone seen this issue before and know how to get the correct NextRunTime value in PowerShell? I'm also seeing the same issue with the LastRunTime value.
I've tried this on Windows Server 2016 and Windows 10 and get the same results on both operating systems.
I can confirm that I see the same issue on Server 2012R2 as well. You can get the correct information by using the task scheduler COM object, getting the root folder (or whatever folder your task is stored in, but most likely its in the root folder), and then getting the task info from that. Here's how you'd do it:
$Scheduler = New-Object -ComObject Schedule.Service
$Scheduler.Connect()
$RootFolder = $Scheduler.GetFolder("\")
$Task = $RootFolder.GetTask("TestTask")
$Task.NextRunTime
Probably also worth noting that you can use the Connect() method to connect to the task scheduler on other computers (if you have rights to access their task scheduler), and get information about their tasks, stop or start their tasks, make new tasks... lots of good stuff here if you don't mind not using the *-ScheduledTask* cmdlets.

send argument/command to already running Powershell script

Until we can implement our new HEAT SM system i am needing to create some workflows to ease our currently manual user administration processes.
I intend to use Powershell to execute the actual tasks but need to use VBS to send an argument to PS from an app.
My main question on this project is, Can an argument be sent to an already running Powershell process?
Example:
We have a PS menu app that we will launch in the AM and leave running all day.
I would love for there to be a way to allow PS to listen for commands/args and take action on them as they come in.
The reason I am wanting to do it this way is because one of the tasks needs to disable exchange features and the script will need to establish a connection a remote PSsession which, in our environment, can take between 10-45 seconds. If i were to invoke the command directly from HEAT (call-logging software) it would lock up while also preventing the tech from moving on to another case until the script terminates.
I have searched all over for similar functionality but i fear that this is not possible with PS.
Any suggestions?
I had already setup a script to follow this recommendation but i was curious to see if there was a more seamless approach
As suggested by one of the comments by #Tony Hinkle
I would have the PS script watch for a file, and then have the VBScript script create a file with the arguments. You would either need to start it on another thread (since the menu is waiting for user input), or just use a separate script that in turn starts another instance of the existing PS script with a param used to specify the needed action

Do AutoIt scripts, executed as service, function for GUI actions?

I'm using an AutoIt script to start and automate a GUI application. I need to activate the script each hour.
Will AutoIt scripts (which perform actions on a GUI) work when used as a service? The script will be run as a service (not scheduled task).
You can easily make an autoit script run as a service using service.au3 written by archer of the autoit forums. Unfortunately or fortunately since it is a security measure. A service needs to start independent of the current user session (before login). It cant access send APIs for input manipulation of the current user session from there. It does sound much more like you need a scheduled task and not a service.
As mentioned above, a scheduled task is what you're looking for. To run a script as a service read this:
Q4. How can I run my script as a service?
This is also a question with multiple answers, and none of them are the only way to do it. The first question to ask yourself is whether or not you wish to install the service on other computers besides your own.
A1. If you only wish to install the service on your own computer, The easiest way to do this is to use Pirmasoft RunAsSvc. This program makes services easy to install and easy to remove when necessary.
A2. If you wish to make the service available to anyone running your script, you can use SRVANY.EXE and ServiceControl.au3. You can then use this code to install your script as a service:
#include "ServiceControl.au3"
$servicename = "MyServiceName"
_CreateService("", $servicename, "My AutoIt Script", "C:\Path_to_srvany.exe", "LocalSystem", "", 0x110)
RegWrite("HKLM\SYSTEM\CurrentControlSet\Services\" & $servicename & "\Parameters", "Application", "REG_SZ", #ScriptFullPath)
or use the following code to delete this service:
#include "ServiceControl.au3"
$servicename = "MyServiceName"
_DeleteService("", $servicename)
There is one caveat to setting up AutoIt as a service. If the service is not installed using the above code, it must have the "allow service to interact with the desktop" setting or else automation functions such as Control* or Win* functions will not function. To assure the service does indeed have this setting, use the following code:
RegWrite("HKLM\SYSTEM\CurrentControlSet\Services[ServiceName]", "Type", "REG_DWORD", 0x110)
Taken from the FAQ topic on the AutoIt Forums. www.autoitscript.com/forum/index.php?showtopic=37289)
It sounds like you're want to use a scheduled task instead of a service. Scheduled tasks can execute every hour, while you're logged in, and should also be able to interact with your desktop. Just remember that a task run as a normal user can not interact (send input) to a elevated program if you're using Vista/Windows Server 2008 with User Account Control enabled.

Resources