One thing I love about working in Information Technology is the opportunity - the NEED - to constantly learn new things. If a week goes by in which I have not looked up something on StackOverflow or other message boards, I start lobbying my team for more challenges.
This week, I learned the power of running "SCHTASKS.exe" from a command-line script for a remote server in a Microsoft Windows environment.
If you don't know Schtasks, you can read up on it here: https://msdn.microsoft.com/en-us/library/windows/desktop/bb736357(v=vs.85).aspx
In a nutshell, it is the command-line interface for the Windows Task Scheduler, and allows you (or a system administrator) to create, change, run, query, terminate, and delete scheduled tasks on a work-station, either the local one or a remote one.
Not all of the features are available in older versions. In my scenario below, this was relevant as the local computer will be a Windows 8 machine, and the remote server is, shall we say, a much older Windows version. So check the documentation carefully for older versions.
Using Schtasks, we can launch an existing scheduled task on a remote computer with:
schtasks /run /s MyRemoteServer /tn MyScheduledTaskName
The parameters are reasonably straight-forward:
/run executes the existing scheduled task immediately
/s MyRemoteServer specifies the remote machine on which the task exists and is to be run.
/tn MyScheduledTaskName identifies by name the existing task to be run.
Just as important for my purposes, we can also monitor the progress of the scheduled task running on the remote server by querying its status:
schtasks /v /query /s MyRemoteServer /tn MyScheduledTaskName /FO LIST
Again the parameters are straight-forward. The server and task names are the same.
/query pulls information about the state of the scheduled task to display the information.
/v gives that information in Verbose form
/FO identifies the format of the task's information. Here, we ask for it as a LIST but it could also be presented as a TABLE or CSV
I am not a SysAdmin, so I never needed to know about Schtasks. But I am our team's Build Master, with responsibilities for the daily builds, and for several activities around the roughly quarterly release builds. This week, I faced a situation for which Schtasks was the solution.
Here's the scenario.
One key step in our Release Build process is handled by a third-party tool with a fairly restrictive license: it can only be installed on a single machine, and does not permit remote execution. Our company is not willing to pay for the more permissive license, and for various reasons changing the server on which it is installed is not a reasonable option at this time.
Over time, I have been gradually automating more and more of our build processes. In fact, after some discussion, lobbying, and building a home-grown proof-of-concept, we have at last installed a Continuous Integration tool, Jenkins, to handle the builds.
So this week's challenge was: can I find a way to turn a fairly tedious and mindless series of manual steps in our release-build process into an automated event controlled by Jenkins, given that Jenkins and the other 3rd-party tool will not ever be on the same server?
Schtasks.exe to the rescue.
First, I experimented with the command-line interface of the 3rd-party tool until I could trigger its steps in our build process from the command line rather than the GUI.
Next, I put those commands into a .bat file, and used Task Scheduler on the server to define the running of the file as a scheduled task. I considered leaving the task Disabled and using Schtasks to enable it, run it, and then re-disable it. But alas the /ENABLE parameter is not recognized in the server's older OS. Instead, I scheduled it to Run Once, at a far-future date. (Should I have used a past date? Maybe. But it won't hurt anything in the build process if this step hits the scheduled time and runs, separate from the rest of the build.)
Finally, I defined a Jenkins build task that runs Schtasks /run for the remote server and task. I had to fiddle a bit with Jenkins' permissions, but soon enough I had a Jenkins build step that would trigger the remote scheduled task.
From the perspective of the 3rd-party tool with the restrictive license, it is being run on the single licensed server.
But now, thanks to Schtasks, one of the more difficult manual steps in our build process has been automated and can be triggered whenever needed from Jenkins.
Learn something new AND automate one of the last manual holdouts of our build process? It was a very good week indeed!
This week, I learned the power of running "SCHTASKS.exe" from a command-line script for a remote server in a Microsoft Windows environment.
If you don't know Schtasks, you can read up on it here: https://msdn.microsoft.com/en-us/library/windows/desktop/bb736357(v=vs.85).aspx
In a nutshell, it is the command-line interface for the Windows Task Scheduler, and allows you (or a system administrator) to create, change, run, query, terminate, and delete scheduled tasks on a work-station, either the local one or a remote one.
Not all of the features are available in older versions. In my scenario below, this was relevant as the local computer will be a Windows 8 machine, and the remote server is, shall we say, a much older Windows version. So check the documentation carefully for older versions.
Using Schtasks, we can launch an existing scheduled task on a remote computer with:
schtasks /run /s MyRemoteServer /tn MyScheduledTaskName
The parameters are reasonably straight-forward:
/run executes the existing scheduled task immediately
/s MyRemoteServer specifies the remote machine on which the task exists and is to be run.
/tn MyScheduledTaskName identifies by name the existing task to be run.
Just as important for my purposes, we can also monitor the progress of the scheduled task running on the remote server by querying its status:
schtasks /v /query /s MyRemoteServer /tn MyScheduledTaskName /FO LIST
Again the parameters are straight-forward. The server and task names are the same.
/query pulls information about the state of the scheduled task to display the information.
/v gives that information in Verbose form
/FO identifies the format of the task's information. Here, we ask for it as a LIST but it could also be presented as a TABLE or CSV
I am not a SysAdmin, so I never needed to know about Schtasks. But I am our team's Build Master, with responsibilities for the daily builds, and for several activities around the roughly quarterly release builds. This week, I faced a situation for which Schtasks was the solution.
Here's the scenario.
One key step in our Release Build process is handled by a third-party tool with a fairly restrictive license: it can only be installed on a single machine, and does not permit remote execution. Our company is not willing to pay for the more permissive license, and for various reasons changing the server on which it is installed is not a reasonable option at this time.
Over time, I have been gradually automating more and more of our build processes. In fact, after some discussion, lobbying, and building a home-grown proof-of-concept, we have at last installed a Continuous Integration tool, Jenkins, to handle the builds.
So this week's challenge was: can I find a way to turn a fairly tedious and mindless series of manual steps in our release-build process into an automated event controlled by Jenkins, given that Jenkins and the other 3rd-party tool will not ever be on the same server?
Schtasks.exe to the rescue.
First, I experimented with the command-line interface of the 3rd-party tool until I could trigger its steps in our build process from the command line rather than the GUI.
Next, I put those commands into a .bat file, and used Task Scheduler on the server to define the running of the file as a scheduled task. I considered leaving the task Disabled and using Schtasks to enable it, run it, and then re-disable it. But alas the /ENABLE parameter is not recognized in the server's older OS. Instead, I scheduled it to Run Once, at a far-future date. (Should I have used a past date? Maybe. But it won't hurt anything in the build process if this step hits the scheduled time and runs, separate from the rest of the build.)
Finally, I defined a Jenkins build task that runs Schtasks /run for the remote server and task. I had to fiddle a bit with Jenkins' permissions, but soon enough I had a Jenkins build step that would trigger the remote scheduled task.
From the perspective of the 3rd-party tool with the restrictive license, it is being run on the single licensed server.
But now, thanks to Schtasks, one of the more difficult manual steps in our build process has been automated and can be triggered whenever needed from Jenkins.
Learn something new AND automate one of the last manual holdouts of our build process? It was a very good week indeed!