For my project purposes, we need to schedule a job which invokes an C# exe file.
I know that we can have a batch file to invoke the exe file and schedule it using TWS.
I just want to know whether we can directly invoke an exe file from TWS
TWS stands for Tivoli Workload Scheduler. It is now marketed by IBM as Tivoli Workload Automation.
Yes you can schedule a job which invokes an exe file. Basically, TWS emulates what a user is doing in a interactive session. If you can log to a server, start a command prompt and start you exe (and append arguments as needed), then TWS will do the same if you code the job right. It will provide you logs and return code handling too.
Related
Have created exchange script to monitor server health check. The script can be run through exchange management shell with no issue and send email html report as expected. But When i am scheduling using task scheduler i get no error message in history tab.
Below are details mention in task scheduler
action tab - program/script :- c:\windows\sysytem32\Windowspowershell\v.1.0\powershell.exe
Add argument (optional) :- -file ""
The script runs well in exchange management shell but not in task scheduler using the above way. Is there any ways where we can run script using exchange management shell using task scheduler so that it works expected
Any help suggestions or screenshot will be helpful.
SSIS package runs multiple Process tasks (5) in parallel which call / invoke the same powershell script (with different parameters being passed to it). The package works great when running locally on my machine, but when deployed to an Integration Services Catalog in SQL Server on a windows server, only 4 out of the 5 Process Tasks are calling the powershell script. Does anyone know of a setting that might be preventing the 5th Process Task from calling the Powershell script? Or is there a way I should be calling a single powershell script so that it can be processed simultaneously on a server?
I have to think this is a solved issue but I am just not getting it to work. So I have come to you StackOverflow with this issue:
I have a windows server 2016 machine running in amazon ec2. I have a machine.ps1 script in a config directory.
I create an image of the box. (I have tried with checking noreboot and unchecking it)
When I create a new instance of the image I want it to run machine.ps1 at launch to set the computer name and then set routes and some config settings for the box. The goal is to do this without logging into the box.
I have read and tried:
Running Powershell scripts at Start up
and used this to ensure user data was getting passed in:
EC2 Powershell Launch Tools
I have tried setting up a scheduled task that runs the machine.ps1 on start up (It just hangs)
I see the initializeInstance.ps1 on start up task and have tried to even coop that replacing the line to run userdata with the line to run my script. Nothing.
If I log into the box and run machine.ps1, it will restart the computer and set the computer name and then I need to run it once more to set routes. This works manually. I just need to find a way to do it automagically.
I want to launch these instances from powershell not with launch configurations and auto scale.
You can use User data
Whenever you deploy a new server, workstation or virtual machine there is nearly always a requirement to make final changes to the system before it’s ready for use. Typically this is normally done with a post-deployment script that might be triggered manually on start-up or it might be a final step in a Configuration Manager task sequence or if you using Azure you may use the Custom Script Extension. So how do you achieve similar functionality using EC2 instances in Amazon Web Services (AWS)? If you’ve created your own Amazon Machine Image (AMI) you can set the script to run from the Runonce registry key, but then can be a cumbersome approach particularly if you want to make changes to the script and it’s been embedded into the image. AWS offers a much more dynamic method of injecting a script to run upon start-up through a feature called user data.
Please refer following link for ther same:
Poershell User data
Windows typically won't let a powershell script call another powershell script unless it is being run as Administrator. It is a weird 'safety' feature. But it is perfectly okay to load the ps1 files and use any functions inside them.
The UserData script is typically run as "system". You would THINK that would pass muster. But it fails...
The SOLUTION: Make ALL of your scripts into powershell functions instead.
In your machine.ps1 - wrap the contents with function syntax
function MyDescriptiveName { <original script contents> }
Then in UserData - use the functions like this
# To use a relative path
Set-Location -Path <my location>
# Load script file into process memory
. <full-or-relpath>/machine.ps1
# Call function
MyDescriptiveName <params-if-applicable>
If the function needs to call other functions (aka scripts), you'll need to make those scripts into functions and load the script file into process memory in UserData also.
I have a simple .exe on a network share that merely creates a dummy file on a network share. The program works. I've wrapped it in a .bat file, a .ps1 file, and a .vbs file, and they all work. However, when I create a SCOM rule to invoke any of these beasts it does not run. Am I missing a management pack or building the rule wrong such that SCOM doesn't run my module? What's the secret to having SCOM run an external module? Thanks.
First, Does your SCOM Agent's RunAs account have permission to access the file?
Most folks deploy the SCOM agent and leave it running under a local account.
Second, if this is a custom authored rule, is your rule properly configured to run on the target system or is it running on the management server? ( what is your target? )
With the basics covered, I have a hunch that your SCOM rule is executing PowerShell based on your use of 'invoke'. If you run PowerShell remotely without enabling CredSSP then you wont be able to make an authenticated connection to the file share downstream.
This guy explains it better then I can: https://4sysops.com/archives/using-credssp-for-second-hop-powershell-remoting/
If this is not the issue can you paste in the actual action the rule is taking?
I am using Putty to transfer files from my windows machine to Linux machine.
I am able to transfer, when i run the script and also if i run the same script using Schedule task with my credentials.
if schedule the task to run using system account(SYSTEM) or other user account, file transfer not happening.
Do i need to save any session vales?
PuTTY saves session information in the registry for the current user only, this information will simply be not available for the other accounts you mentioned. So you either need to provide them by exporting yours and importing them in the other user's accounts or simply provide everything needed on the shell command invoked to copy your files. The latter sounds much easier to me in combination with a little script which gets invoked by the task scheduler.