MQ MFT With Powershell - ibm-mq

IBM WS MQ7.5, windows MQMFT agent, linux MQ manager.
I am trying to run a powershell script as defined in the xml of a MQ mft ant script.
I configured the path to the powershell scripts in commandPath of the agent.properties files.
The managed call starts but fails
<fte:presrc command="C:\IBM\MFT\script\MoveFileToArchive.ps1" successrc="0">
<fte:arg value="${base.file}"/>
</fte:presrc>
The error reads
cannot run program createprocess error=193 MoveFileToArchive.ps1 is not a valid win32 application
I tried to add the path to powershell with powershell.exe defined like so
<fte:presrc command="C:\windows\system\windowspowershell\v.1.0\powershell.exe C:\IBM\MFT\script\MoveFileToArchive.ps1" successrc="0">
<fte:arg value="${base.file}"/>
</fte:presrc>
This doesnt work either.

As can be seen from the error, MFT agent is using CreateProcess API to start a program. CreateProcess API can run only executable file. The Powershell script you are using is a non executable. Hence the error.
If you want to be able to open any file with its associated application then you need ShellExecute instead of CreateProcess. But this is not under your control. So need to look for alternative?
Try using a batch file say ps.cmd and in the batch file you run the PowerShell script like
Powershell -executionpolicy bypass -File C:\IBM\MFT\script\MoveFileToArchive.ps1 %1
Where %1 would be the argument for PS script.
The Ant script also needs bit of a change.
<fte:presrc command="ps.cmd" successrc="0">
<fte:arg value="${base.file}"/>
</fte:presrc>
I am sure you have already set the commandPath property to a suitable value in agent.properties.
Give it a try.

Related

Automating google cloud SDK installation on windows, GCLOUD is not recognized as an internal or external command

I am using following batch file to download and unzip the google-cloud-sdk,
file name: download.bat
set home=%USERPROFILE%
echo %home%
%WINDIR%\System32\WindowsPowerShell\v1.0\powershell.exe -Command "(New-Object Net.WebClient).DownloadFile('https://dl.google.com/dl/cloudsdk/channels/rapid/downloads/google-cloud-sdk-179.0.0-windows-x86_64-bundled-python.zip', '%home%/google-cloud-sdk.zip');& { Add-Type -A 'System.IO.Compression.FileSystem'; [IO.Compression.ZipFile]::ExtractToDirectory('%home%/google-cloud-sdk.zip', '%home%/google-cloud-sdk'); }"
and I am using following batch file to install the SDK silently on windows,
file name: install_win.bat
call %USERPROFILE%\google-cloud-sdk\google-cloud-sdk\install.bat --path-update=true --usage-reporting=false --command-completion=false
After these steps are completed successfully when I try to authorize my serice account from another batch file using the following command,
gcloud auth activate-service-account --key-file {json fila path}
It fails and tells me that the glcoud is not recognized internal or external command.
Can anyone please help me solve this error?
I think the error is because of the lack of environment variable in windows with the bin file of SDK.
How to set that from the batch file?
The ...cloud...\install.bat routine is called, hence it inherits the calling routine's environment. It does not communicate any changes back to the calling routine.
Since I'd assume that the install.bat is supplied by a 3rd party, hence cannot be altered, then you would need to retrieve the new path for the current cmd instance.
call %USERPROFILE%\...\install.bat ...
FOR /f "delims=" %%a IN ('echopath') DO SET "newpath=%%a"
where echopath.bat is simply one line:
echo %path%
Provided echopath.bat is reachable - and it must be a separate file, not an internal routine - the new path should be returned (to newpath in this instance - I'll let you guess what changes you'd need to make to change that to path...)
Since executing an external batch loads the environment anew, the modified environment path will be reported by echopath and hence assigned to the variable nominated.

How to Detect 'Batch' mode from within a Batch File under Windows

I'm running a batch (.bat) file via the Windows (Task) Scheduler, a third party cron (nncronLite) and via a "START" command. I'm trying to work out a way that I can detect the .bat file has been run via one of the above means compared to me running the batch file from a console (cmd.exe) window.
I can try checking an environment variable.. but which one (here I'm trying HOMEDRIVE)?
setlocal
set BATCH_MODE=1
if defined HOMEDRIVE set BATCH_MODE=
rem [...]
if defined BATCH_MODE echo IN BATCH MODE
Any other suggested mechanims (other than supplying a command line argument to the batch file = kludge, IMO)?
This is for use with Windows XP, Win7, Win8, Win10 (and beyond, I guess)
Thanks.

Batch file is working from cmd prompt but not from IIB tool

I have wrapped a simple perl command in a simple windows batch file and executed the same from cmd prompt which worked as expected.
But if I trigger the same batch file from my message flow in IBM Integration Bus, it is unable to recognize the 'perl' command.
Provided the environment variables are set properly and the batch file is working fine from command prompt.
Can anyone please help me on this to identify the issue and resolve the same?
Thanks for the reply.
Actually the error was related to the path from where the batch is calling the perl command.
IIB was always executing it from it's runtime path and that's why it could not recognize the perl command.
The clue is to execute the batch from the path where the perl.exe is present. By following the same the issue got resolved.

Not identifying custom cmdlets when the batch file to launch a powershell script is invoked through a window service

I've a Powershell script which consists of custom cmdlets which are stored in Powershell profiles.
I made a batch file to invoke that script which will look like this:
powershell.exe C:\MyScript.ps1 -remoteMachinesList ABC123,ABC456 -TestServer xxx.xxx.xx.xxx -TestVersion 3.7
When I run this batch file normally(by double clicking), the script runs properly identifying the custom cmdlets used in the script.
But when I invoke the same via a windows service, the batch file is invoked, which in turn launches the powershell script and it says the term is not recognized as the name of a cmdlet, funtion, script file, ... and it closes the window. I'm able to see the GUI because I'm calling the cmd.exe application using 'StartProcessAndBypassUAC' in the windows service.
What's the difference it makes here so that it is not identifying the custom cmdlets? I can see that both ways opens the cmds and powershell windows in admin mode itself.
Please help.

Bamboo Remote Agent Does Not Recognized Windows command or exectuables

I started trial with Bamboo recently. I ran bamboo server on my personal PC and configure our build server to be a remote agent. Our build environment is in Windows. The build process is carried out via TCL script, which basically executes Windows batch command to build different stuffs. The remote agent execute that TCL script after source code checkout. However, the Windows commands that are suppoesed to execute do not actually execute. For example, if we try to execute msbuild batch command from windows, we will do
exec "cmd << msbuild **.sln"
in the TCL script. The result of this command is 'msbuild' is not recognized as an internal or external command, operable program or batch file. The problem was gone for two builds then re-appear right after.
I tried just simply called the script from CMD on the remote agent and aslo execute the job on my PC(which is the default agent) through Bamboo. The mentioned problem does not occur.
Can anyone tell me if there are some other configurations that I have missed?
Thank you.
Well, your command:
exec "cmd << msbuild **.sln"
That's not going to work (unless you have a program called exactly that, which I think is illegal on Windows; you can't have * in a file name). Instead, you need to invoke it either via cmd or using a direct Tcl style invoke.
Which one will be best? I don't know; try them and find out for yourself.
Invoking via cmd.exe
exec cmd /c msbuild *.sln
Invoking a more Tcl-ish style
exec msbuild {*}[glob *.sln]
(Note that I think ** is always unnecessary as * just means “any number of any character” when expanding a glob. If you're using it to mean “recursive search through a directory structure”, say so and I'll provide code to do it using the find command in the Tcllib fileutil package.)

Resources