Automic Workload Automation

  • Private Community
Back to discussions
Expand all | Collapse all

How to set up a Windows Agent to run Powershell jobs

  • 1.  How to set up a Windows Agent to run Powershell jobs

    Posted Feb 07, 2013 10:14 PM
    The information below can also be found in our Knowledge Base (KB0010526). Detailed Description and Symptoms By default, a Windows Agent cannot run powershell scripts unless it's through a .bat file or command that can be run at the Windows command line.  Below are instructions on setting up a Windows Agent to have a Powershell interpreter. Investigation Setting up the interpreter: 1) Find the path to powershell.exe that will be used.  Please note, a 32-bit agent can only use 32-bit powershell which is found (by default) in the C:\WINDOWS\SysWOW64\windowspowershell directory. 2) Open the agent's ini file and in the [GLOBAL] section, change the ECPEXE setting to the full path to powershell.exe.  Change the ECPEXT setting to ps1.  An example is below: ECPEXE=C:\WINDOWS\SysWOW64\windowspowershell\v1.0\powershell.exe ECPEXT=ps1 3) Restart the agent Solution Running a job on the interpreter To run a job on the Windows Agent using the interpreter, open the Windows job and go to the WINDOWS tab.  Under "Type", choose "Interpreter". Any JCL or command that is put into the Pre-Process or Process tab will now be run in Powershell rather than via Windows command line.


  • 2.  How to set up a Windows Agent to run Powershell jobs

    Posted Oct 08, 2013 03:31 AM
    This works only if the full path to the temporary job scripts folder (UC_EX_PATH_TEMP) does not contain any spaces. If for example the UC4 Agent is installed in C:\Program Files\UC4\Agent, all jobs of type Interpreter will fail. This bug has been documented in PRB0306576. Until the bug is fixed, you must either move the agent to a directory whose full path contains no spaces, or change UC_EX_PATH_TEMP so that it refers to a directory whose full path contains no spaces.


  • 3.  How to set up a Windows Agent to run Powershell jobs

    Posted Oct 08, 2013 03:45 AM
    PowerShell return codes and exceptions are not currently handled very well by the UC4 Windows agent. The system includes (JOBIs) for Windows agent jobs appear to be designed with BAT scripts in mind. A rudimentary work-around is to include the following instructions in the end of every PowerShell interpreter job:
    $RC = $? echo "RC=$RC" switch ($RC)     {         True { $EXIT_CODE = 0 }         False { $EXIT_CODE = 1 }         default { $EXIT_CODE = 1 }     } exit $EXIT_CODE
    I think updated system includes that take PowerShell into account might be a better approach. I got this idea from Philipp Elmer’s Automic Blog.
    :SET &ATT_WIN_TYP = GET_ATT(WIN_TYP) :SET &ATT_HOST = GET_ATT(HOST) :IF &ATT_WIN_TYP = "EXTCOMPROC" !  Update this list to include systems with the PowerShell interpreter configured :  IF &ATT_HOST = "CHRV3225" OR "CHRV3016" !  Do handling for PowerShell jobs here... :  ENDIF :ENDIF
    Has anyone found a good solution to this problem?


  • 4.  How to set up a Windows Agent to run Powershell jobs

    Posted Nov 22, 2013 04:08 AM

    If you do "serious" PowerShell programming/scripts, the returncode of a single command is not that relevant (since you will probably execute many PowerShell commands in a single script), is it?

    100% of our jobs are written in PowerShell (since we have Windows only hosts), and we handle returncodes etc. inside PowerShell (e.g. with a trap statement) that generate output which is subsequently handled in post-processing.

     



  • 5.  How to set up a Windows Agent to run Powershell jobs

    Posted Jan 24, 2014 03:13 PM



  • 6.  How to set up a Windows Agent to run Powershell jobs

    Posted Nov 27, 2017 11:04 AM
    Michael A. Lowry wrote:
    This works only if the full path to the temporary job scripts folder (UC_EX_PATH_TEMP) does not contain any spaces. If for example the UC4 Agent is installed in C:\Program Files\UC4\Agent, all jobs of type Interpreter will fail. This bug has been documented in PRB0306576. Until the bug is fixed, you must either move the agent to a directory whose full path contains no spaces, or change UC_EX_PATH_TEMP so that it refers to a directory whose full path contains no spaces.
    I saw this bug again today in v12.0.3. The work-around I have in place is to use an 8.3-style paths. E.g.,
    UC_EX_PATH_TEMP = C:\PROGRA~1\UC4\agent\jobs\
    UC_EX_PATH_JOBREPORT = C:\PROGRA~1\UC4\agent\out\
    I can no longer view the old problem ticket. Does anyone know if there is a solution to this, or a new problem ticket?


  • 7.  How to set up a Windows Agent to run Powershell jobs

    Posted Nov 27, 2017 11:34 AM
    Building off this, there is the External Interpreter functionality I believe came out with V11.2? Worth checking out for other interpreters including powershell:

    https://docs.automic.com/documentation/webhelp/english/AWA/12.1/DOCU/12.1/AWA%20Guides/help.htm#AE_AWA_Source/Script/ucsaef.htm


  • 8.  How to set up a Windows Agent to run Powershell jobs

    Posted Nov 27, 2017 11:58 AM
    Michael_Pirson: The external interpreters function is also affected by this bug.


  • 9.  How to set up a Windows Agent to run Powershell jobs

    Posted Nov 27, 2017 12:52 PM
    We use both the agent interpreter feature and the external interpreter feature.  If a process script is going to be 100% Powershell, then we use the agent interpreter mode.  If a process script needs to employ both DOS commands and Powershell commands, then we use the external interpreter feature.

    We did not encounter the mentioned bug because we didn't install the product under "Program files".

    We use the rudimentary error handling technique that Michael posted above.





  • 10.  How to set up a Windows Agent to run Powershell jobs

    Posted Nov 28, 2017 07:54 AM
    I opened a new incident for this, INC00216353.
    If UC_EX_PATH_TEMP in the Windows agent ini file points to a path that contains a space, any interpreter jobs will fail. This applies to jobs of type Interpreter as well as external interpreter jobs. A work-around is to use 8.3-style pathnames.

    Does not work:
    UC_EX_PATH_TEMP = ..\jobs\
    UC_EX_PATH_TEMP = C:\Program Files\UC4\agent\jobs\
    UC_EX_PATH_TEMP = 'C:\Program Files\UC4\agent\jobs\'
    UC_EX_PATH_TEMP = "C:\Program Files\UC4\agent\jobs\"
    Works:
    UC_EX_PATH_TEMP = C:\PROGRA~1\UC4\agent\jobs\
    I reproduced this problem using PowerShell interpreter jobs. I could see by enabling extended reports that the agent was executing the interpreter job without escaping the space character or enclosing the path in quotes:
    powershell.exe -NonInteractive C:\Program Files\UC4\agent\Resources\0001\0020866036\0020866036_0001.ps1
    This resulted in the following error:
    20171128/133753.007 - U02001095 Job '20869033' requested task-specific ressource '1:INTERPRETER/EXT_INT_0001'.
    20171128/133753.068 - U02001097 Job '20869033' use task-specific ressource '1:INTERPRETER/EXT_INT_0001' - 'C:\Program Files\UC4\agent\Resources\0001\0020869033\0020869033_0001.ps1'.
    C:\Program : The term 'C:\Program' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
    At line:1 char:1
    + C:\Program Files\UC42\agent\jobs\JABTRJJD.TXT.ps1
    + ~~~~~~~~~~
        + CategoryInfo          : ObjectNotFound: (C:\Program:String) [], CommandNotFoundException
        + FullyQualifiedErrorId : CommandNotFoundException
    I also tried enclosing the path specified by UC_EX_PATH_TEMP in single or double quotation marks, but this did not work either.

    I’ll provide an update here when I have news.



  • 11.  How to set up a Windows Agent to run Powershell jobs

    Posted Nov 28, 2017 11:57 AM

    I have learned a bit more about the agent variables involved in this problem:

    • UC_EX_PATH_TEMPplays a role in all OS jobs, including ordinaryInterpreter-type Windows jobs. It is used to store a temporary copy of the generated job script¹.
    • UC_EX_JOB_MDplays a role inBAT- andCOM-type Windows jobs. It is used to run the job messenger.
    • UC_EX_PATH_CACHEplays a role in external interpreter jobs. It is used to save a copy of the external interpreter script for each:BEGIN_EXT_INTERPRETER … :END_EXT_INTERPRETER block in a job.

    So:

    1. If you run any kind of OS job, you must ensure thatUC_EX_PATH_TEMPdoes not contain spaces.
    2. If you runBAT- orCOM-type Windows jobs, you must ensure thatUC_EX_JOB_MDdoes not contain spaces
    3. If you run external interpreterjobs, then you must ensure thatUC_EX_PATH_CACHEdoes not contain spaces.


    If you want to be extra safe, just use 8.3-style paths in all of the relevant agent variables. E.g.:

    [VARIABLES]
    UC_HOST_CODE = UC_CODE
    UC_HOST_JCL_VAR = WINDOWS

    ; Path to AE Agent executables
    UC_EX_PATH_BIN = C:\PROGRA~1\UC4\agent\bin\

    ; Path to job messenger
    UC_EX_JOB_MD = C:\PROGRA~1\UC4\agent\bin\UCXJWX6M.EXE

    ; Directory for temporary job JCL
    UC_EX_PATH_TEMP = C:\PROGRA~1\UC4\agent\jobs\

    ; Directory for external interpreter jobs
    UC_EX_PATH_CACHE = C:\PROGRA~1\UC4\agent\resources

    ; Directory for job reports (logs)
    UC_EX_PATH_JOBREPORT = C:\PROGRA~1\UC\agent\out\

    ; Backup directory
    UC_EX_PATH_BACKUP = C:\PROGRA~1\UC4\agent\BACKUP\

    Notes:
    1. One can save a copy of the generated job script of by enabling extended reports. After you have run the job, look at the JCL tab of the job report. The generated job script will be everything below the ”JCL:” heading.



  • 12.  How to set up a Windows Agent to run Powershell jobs

    Posted Dec 01, 2017 12:06 PM
    Automic Support replied, and said that the agent is working as designed. The installation guide includes this warning:
    Do not use directory names for the Automation Engine and the Agents that include blanks.
    This documentation page refers to a Microsoft Support article: Long filenames or paths with spaces require quotation marks.

    Because the AE Agent does not handle quotation marks as Microsoft suggests, 8.3-style names are the only work-around.