Workload Automation

Expand all | Collapse all

plumbing windows jobs to powershell files

Jump to Best Answer
  • 1.  plumbing windows jobs to powershell files

    Posted 10-22-2019 09:47 AM
    ​Hi.  I just got started with ca workload automation.  I've created an event and set up a related series of 4 jobs connected by dependencies in my app.  I have links on the front and back also for what I understand could support inter app dependencies later.  I've set up various user accounts for dev test, etc.

    I'd like to relate each job to a powershell script that would be executed when that job runs but don't understand how agents, servers and the command line come into play at this juncture.  Or if an agent is even necessary.  I get the feeling agents relate to a server and are woken up by ca wa.  I cant find any documentation on this subject, especially the setting up of agents.

     I see the "command to run" text box related to each job when I rt click and edit..  its been recommended to me that the agent group be a ca variable.  Can somebody fill me in a little on what my options are and where I would go from here?

    jobs with dependencies



  • 2.  RE: plumbing windows jobs to powershell files
    Best Answer

    Posted 10-22-2019 11:02 AM
    Hi,
    You would need an agent installed on the windows server(s).  If you want to use an agent group you would set that up in ADMIN - Topology with all the agents the job can run on.  On the application properties you would specify the agent or agent group that the majority of the jobs would use.  On the jobs for agent if you leave application default checked will take whatever server is on the application properties, if you want you can uncheck and put another agent there. Also, on the job you would fill in the script/command to run and any arguments the script needs. ​Sometimes you need a userid and sometimes you do not.  If you do need a userid, that userid and password would have to be added to the agent in ADMIN - Topology and the userid would go on the job.


  • 3.  RE: plumbing windows jobs to powershell files

    Posted 10-22-2019 12:15 PM
    thx, you have answered the question so this is just gravy.  from your experience do larger companies share the ​same servers for housing ps scripts belonging to multiple business groups or do the groups themselves leverage existing file servers they already own?  The reason I ask is that management and purposing would seem more economical using the first choice.  But perhaps ps cmdlet "installs" can rock (in a bad way) one group's world while trying to satisfy the needs of another.


  • 4.  RE: plumbing windows jobs to powershell files

    Posted 10-22-2019 12:44 PM
    we have a script that is reusable by many apps that is housed on a centeral server and through the script and arguments goes to the appropriate server.  For app specific scripts they are server specific (or possibly 2 servers for HA) for security reasons.  ​


  • 5.  RE: plumbing windows jobs to powershell files

    Posted 10-22-2019 01:29 PM
    thx, ours are all app specific but the user id under which the ca jobs run would (I hope) take care of any security concerns.​


  • 6.  RE: plumbing windows jobs to powershell files

    Posted 11-05-2019 05:42 PM
    Our bigger business groups have dedicated servers for their line of business, in part because they have dedicated developers who actually code the scripts we schedule.
    We do have a good share of shared servers as well though.

    I sense your questions have been answered, but here is how we have things set up.

    Agent:  In order to make it easy to move DE applications between various environments (Dev, Stage, Prod) we use a variable for the Agent Name.  If the application is run in Dev, the agent variable will resolve to a a development server ( ex. FTPD04), and if the same application is copied and run in Prod the agent will resolve to the equivalent production server (ex FTPP04)

    Command to run: if you want to execute Powershell then this field should be:
    C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

    Arguments to pass: again, if you are executing Powershell the first argument you will likely pass to it is the path to the PS1 file you want to run.:
    -command "C:\Cyb_exec\your_powershell.ps1"

    If your powershell is short enough to fit onto one line, you can just put the whole command into the Argument to pass.  For example, the following command will strip a 16 character timestamp from filenames of the files in a specific folder.

    Get-ChildItem -Path D:\Inetpub\FTProot\PROD\IN\*.csv | foreach { rename-item $_.FullName -newname ($_.BaseName.Substring(0,$_.BaseName.length - 16) + $_.Extension)}

    ------------------------------
    Andy Reimer
    ------------------------------



  • 7.  RE: plumbing windows jobs to powershell files

    Posted 11-06-2019 08:44 AM
    Edited by stan teitelbaum 11-06-2019 09:29 AM
    thx Andy, that brings up an interesting question for me.  We put the full path to the ps1 file in the ca command rather than a reference to an exe.  My thinking was that the os would relate that file type to powershell and execute accordingly the same way it does when i double click on ps1 files on other servers.

    We know the job isnt working when i trigger it from the client.  i asked for permission to rdp to the server so i can try to double click the file myself and determine if perhaps ps cmdlets havent been installed.  The idea would be to determine if the problem is downstream of ca or upstream.  i have to wait till fri 11/8 to get that rdp permission.

    In the mean time i'm a little unclear on how the name of a file as a parameter would be passed to the exe (arguments to pass).  Would it be on the same line  in the ca command or via another text box.  I'm going back to the client now to familiarize myself with the options.  If its in a separate box, i have to wonder how one param is differentiated from potentially others.  Maybe its that -command designation you showed

    I did go back and enter the ps exe in the command ...and then -command followed by the full ps1 path in quotes in the arg to pass... and then simulate.  Same results (none).  This is probably on us to figure out, not the forum.


  • 8.  RE: plumbing windows jobs to powershell files

    Posted 11-06-2019 12:20 PM
    By default Windows does not execute a PS1 file when it is double clicked.  It opens it in Notepad.  There are presumably ways around this, but it would likely require changes in the user id profile that matched the User ID specified on the job description.  My guess is if you schedule a job to run and nothing is happening, you will find a notepad.exe process running under the user id the agent is using.

    I was going to upload an image of one of our powershell jobs but for some reason (site / browser / security / who knows) I can't load images into the forum post. but here are some exact values we use.

    Command to run: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
    Argument to Pass: -command "C:\Cyb_exec\PatchNight\Reboot_Server.ps1" SQLP25CAWM

    Powershell can handle both named and positional arguments.  In this case the first argument is named by -command and specifies which PS1 file to run.  The second argument is technically the first argument that will be passed into the PS1 (in this case the name of a server I want to reboot).

    ------------------------------
    Andy Reimer
    ------------------------------



  • 9.  RE: plumbing windows jobs to powershell files

    Posted 11-06-2019 01:54 PM
    Edited by stan teitelbaum 11-06-2019 01:56 PM
    thx Andy , that resonates with me.  I think when i originally (long time ago) tested the ps to sql server plumbing downstream of ca on test servers, a ps window opened up where i had to choose an exec icon under ps ise to actually run the script.  And of course that choice was probably a server by server decision based on certain settings, probably default settings.  I'll revisit that exercise and post back here.

    If that's the case, the possibilities get narrower.  And most probably the user id (really a non expiring nt account) we assigned to the ca d series job doesnt have exec privileges on ps on the agent machine.  we gave it exec on the directory where the ps file resides but that is starting to sound like the wrong way to go.


  • 10.  RE: plumbing windows jobs to powershell files

    Posted 11-07-2019 07:39 AM
    did due diligence and indeed this worked the way you said Andy.  Below is a summary of what I did.  I will be going back to the ca client and entering the exe as the command , ps1 file as the argument to pass the way you showed and I will also get exec permission on the path to poweshell itself for the non expiring user we have on the job.  For good measure, I'll make sure the userid also has read on the path to the ps1 file even though it already has exec.  I'll probably request removal of the exec permission the non expiring userid has on the path to the ps1 file.

    going back to powershell testing in prep for setting up ca differently, i went to testserver, double clicked
      C:\...\catopowershelltestsqlbased.ps1 and indeed notepad opened up.  I right clicked the same and chose run with powershell and the record did show up
      (the test script inserts a record on a different server that is sql) on [db].[stan].[catopowershelltest].  I ran the full path in ps ise in the command line area
      (bottom) and the record also got inserted.  I rt clicked the file, hit edit and the script showed up in the ise's script area.  i ran it from there with the green
      arrow and the record showed up. ​


  • 11.  RE: plumbing windows jobs to powershell files

    Posted 11-07-2019 10:16 AM
    Excellent well-presented responses from Andy ! ! !

    In my environment powershell.exe is in the path, so the example below works.

    NT_JOB PWRSHELL  
      AGENT <Agent Name>                                            
      CMDNAME powershell.exe                                             
    /*CMDNAME C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe */

    The advantage I see is that in the future if PowerShell is moved the ESP Job will still work.

    The other issue I had in my environment is that the script did not exit with the proper exit code.

    I added the function below, then called it with the appropriate exit code value.

    #---------------------------------------------------------------------#
    #   Functions ExitWithCode                                            #
    #---------------------------------------------------------------------#
    function ExitWithCode
    {     param
        (         $exitcode     )
        $host.SetShouldExit($exitcode)
        exit }
    .
    .
    .
    # Last line of Main Program

    ExitWithCode -exitcode $ExitStatus​


     



    ------------------------------
    Senior Systems Analyst
    UPS
    ------------------------------



  • 12.  RE: plumbing windows jobs to powershell files

    Posted 11-07-2019 10:24 AM
    Rick,

    This has worked for us for years as well. However, we now have users that need to run 64 bit Power shell which runs from this path:
    C:\WINDOWS\SYSWOW64\WINDOWSPOWERSHELL\V1.0\POWERSHELL.EXE
    Is there a way in Windows PATH or environment variables to make "powershell.exe" resolve to this?

    Thanks!
    <JC>​


  • 13.  RE: plumbing windows jobs to powershell files

    Posted 11-07-2019 10:52 AM

    If the PATH were updated to reference the 64-bit PowerShell.

    Check out the link below, that may provide what you need without any changes to Windows PATH.

    http://cosmonautdreams.com/2013/09/03/Getting-Powershell-to-run-in-64-bit.html



    ------------------------------
    Senior Systems Analyst
    UPS
    ------------------------------



  • 14.  RE: plumbing windows jobs to powershell files

    Posted 11-07-2019 10:38 AM

    For the elimination of the path in the CMDNAME, make sure the following is set in agentparm.txt

    #
    # Windows Settings
    #
    oscomponent.lookupcommand=true

    Otherwise job will be on CSF as follows:

    Job Name   ApplName     CCode Job Status
    PWRSHELL   PWRSHELL     20007 Command file not found



    ------------------------------
    Senior Systems Analyst
    UPS
    ------------------------------



  • 15.  RE: plumbing windows jobs to powershell files

    Posted 11-07-2019 12:34 PM
    I've considered using the environment path but we run powershell on so many servers and our change control is pretty stringent.  Too much effort.

    The need to use $host.SetShouldExit() is not unique to your environment.  We also use it to ensure the correct exit code is passed back to DE.  Fortunately Powershell has pretty good error handling and the built in $error variable which allows for easy control of what codes to pass back
    ​​

    ------------------------------
    Andy Reimer
    ------------------------------



  • 16.  RE: plumbing windows jobs to powershell files

    Posted 11-14-2019 12:05 PM
    Edited by Heber Solis 11-14-2019 12:29 PM

    Hello, I have a series of jobs that don't do anything I go to the log of the jobs and it says that the job ended successfully but it didn't do anything it is supposed  to just open word, I went to Powershell ISE and entered the same commands and it did all it was supposed to do, I tried what Andy said 

    Command to run: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
    Argument to Pass: -command "C:\Cyb_exec\PatchNight\Reboot_Server.ps1" SQLP25CAWM

     does anyone knows what am I doing wrong? thank you




  • 17.  RE: plumbing windows jobs to powershell files

    Posted 11-14-2019 02:48 PM
    Hi Heber, shot in the dark because I had this problem...if your ps script references the current directory using the wildcard shorthand (I think ./ or something like that), that is no longer valid because its where the exe is when run from CA, not where the script is like when you run powershell directly. ​


  • 18.  RE: plumbing windows jobs to powershell files

    Posted 11-14-2019 03:28 PM

    I'm sorry I didn't understand, I'm very new to CA let me show you my joblog and the agentparm.txt file just to see if you can catch something

    #
    # Agent settings for nt-x86-64
    #

    #
    # Log
    #
    # log.archive settings:
    # 0 - archive with time extension
    # 1 - append ".archive.log"
    # 2 - delete previous log
    # 3 - keep writing to the same log file
    log.level=5
    log.archive=1
    log.maxsize=1M
    #

    #
    # Agent name
    #
    agentname=MXVADM_MX02689

    #
    # Communications
    #
    communication.inputport=7520

    communication.managerid_1=CENTRAL_MANAGER
    communication.manageraddress_1=SCA2011145
    communication.managerport_1=7507
    communication.monitorobject_1=MXVADM_MX02689/AGENTMON1.0/MAIN

    #
    # Security
    #
    security.filename=C:/CA/WA_Agent_R11_3_4/security.txt
    security.level=off
    security.cryptkey=C:/CA/WA_Agent_R11_3_4/cryptkey.txt

    #
    # Initiators
    # There will be separate line for each pair of <class, number of initiators>
    # initiators.class_N, where N is number running from 1 to ...
    # Class is user definable, (should be the same here and in AFM)
    # Soft shutdown mode waits for all jobs to be completed
    #
    initiators.class_1=Default,1000

    #
    # Core parameters
    #
    core.health.monitor.enable=true

    #
    # General characteristics
    #
    spooldir=C:/CA/WA_Agent_R11_3_4/spool
    # Java parameters
    oscomponent.javapath=C:/CA/WA_Agent_R11_3_4/jre/bin
    oscomponent.jvm=server

    # What plugins we want to start by the core Java agent
    plugins.start_internal_1=runner
    plugins.start_internal_2=router
    plugins.start_internal_3=filemon
    plugins.start_internal_4=objmon
    plugins.start_internal_5=filebrowser

    # Jars classpath
    oscomponent.classpath=jars/*.jar;jars/ext/*
    management.snmp.mibfile=C:/CA/WA_Agent_R11_3_4/cybermation.mib

    #
    # What management connectors we want to start by the core Java agent
    #


    #
    # Windows Service name
    #
    oscomponent.servicename=CA Workload Automation Agent 11.3.4
    oscomponent.servicedisplayname=CA Workload Automation Agent 11.3.4

    # Windows Settings
    oscomponent.lookupcommand=true
    oscomponent.noforceprofile=false
    oscomponent.dumpenvironment=false
    oscomponent.initialworkingdirectory=SCRIPT
    agent.spool.success.autocleanup=false
    oscomponent.joblog.success.autocleanup=false
    runnerplugin.spool.clean.enable=true
    runnerplugin.spool.expire=10D
    runnerplugin.spool.sleep=36H
    oscomponent.joblog=true
    oscomponent.cmdprefix.force=true
    oscomponent.interactive=true
    oscomponent.cmdprefix.force.redir.inline=true
    #oscomponent.interactive.session.ignoreinactive=true
    #oscomponent.interactive.sessionzero=true
    oscomponent.logon.elevated=true
    oscomponent.su.newconsole=true
    #oscomponent.shell=true
    #oscomponent.default.user=MXVADM_MX02689
    #oscomponent.default.password=2390hasG

    #
    # Installer setting. Do not modify the setting below
    #
    installer.version=R11.3.4


    #
    # Added by Manager
    #
    communication.managerhealthmon_1=false
    communication.socket_1=plain
    job log

    Thu Nov 14 12:23:33 2019 CAWA_I_20005 AFM: 20191114 12233398+0600 MXVADM_MX02689 JavaAgent#tcpip@CENTRAL_MANAGER 1313262448_HEBER_HELLOPOWER/01_PRUEBA_RUBEN.49/MAIN RUN . Data(Args="-command \"D:/helloworld.ps1\"",Command="C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe") TargetSubsystem(WIN) MFUser(L041409) WOBRequestID(944CD7969DB0E025A90B5BACCA5002861B68D72115737558137380)
    Thu Nov 14 12:23:33 2019 CAWA_I_20008 Agent version: CA Workload Automation Agent for Microsoft Windows R11.3 Build 738
    Thu Nov 14 12:23:33 2019 CAWA_I_20006 --- Environment ---
    Thu Nov 14 12:23:33 2019 CAWA_I_20007 Environment variable: ALLUSERSPROFILE=C:\ProgramData
    Thu Nov 14 12:23:33 2019 CAWA_I_20007 Environment variable: APPDATA=C:\WINDOWS\system32\config\systemprofile\AppData\Roaming
    Thu Nov 14 12:23:33 2019 CAWA_I_20007 Environment variable: AUTOPID=18896
    Thu Nov 14 12:23:33 2019 CAWA_I_20007 Environment variable: CommonProgramFiles=C:\Program Files\Common Files
    Thu Nov 14 12:23:33 2019 CAWA_I_20007 Environment variable: CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files
    Thu Nov 14 12:23:33 2019 CAWA_I_20007 Environment variable: CommonProgramW6432=C:\Program Files\Common Files
    Thu Nov 14 12:23:33 2019 CAWA_I_20007 Environment variable: COMPUTERNAME=MXVADM_MX02689
    Thu Nov 14 12:23:33 2019 CAWA_I_20007 Environment variable: ComSpec=C:\WINDOWS\system32\cmd.exe
    Thu Nov 14 12:23:33 2019 CAWA_I_20007 Environment variable: DriverData=C:\Windows\System32\Drivers\DriverData
    Thu Nov 14 12:23:33 2019 CAWA_I_20007 Environment variable: ESPAGENT=MXVADM_MX02689
    Thu Nov 14 12:23:33 2019 CAWA_I_20007 Environment variable: ESPAGENTDIR=C:\CA\WA_Agent_R11_3_4
    Thu Nov 14 12:23:33 2019 CAWA_I_20007 Environment variable: ESPAGENTHASH=5E05D31D0669D63282BFD750545CA535CA350620
    Thu Nov 14 12:23:33 2019 CAWA_I_20007 Environment variable: ESPAGENTPORT=7520
    Thu Nov 14 12:23:33 2019 CAWA_I_20007 Environment variable: ESPAGENTSPOOL=C:/CA/WA_Agent_R11_3_4/spool
    Thu Nov 14 12:23:33 2019 CAWA_I_20007 Environment variable: ESPAGENTTOKEN=4C303431343039
    Thu Nov 14 12:23:33 2019 CAWA_I_20007 Environment variable: ESPAPGEN=49
    Thu Nov 14 12:23:33 2019 CAWA_I_20007 Environment variable: ESPAPPL=01_PRUEBA_RUBEN
    Thu Nov 14 12:23:33 2019 CAWA_I_20007 Environment variable: ESPAPPLMGR=JavaAgent#tcpip@CENTRAL_MANAGER
    Thu Nov 14 12:23:33 2019 CAWA_I_20007 Environment variable: ESPOBJECT=1313262448_HEBER_HELLOPOWER/01_PRUEBA_RUBEN.49/MAIN
    Thu Nov 14 12:23:33 2019 CAWA_I_20007 Environment variable: ESPWOB=1313262448_HEBER_HELLOPOWER
    Thu Nov 14 12:23:33 2019 CAWA_I_20007 Environment variable: LOCALAPPDATA=C:\WINDOWS\system32\config\systemprofile\AppData\Local
    Thu Nov 14 12:23:33 2019 CAWA_I_20007 Environment variable: NUMBER_OF_PROCESSORS=4
    Thu Nov 14 12:23:33 2019 CAWA_I_20007 Environment variable: OS=Windows_NT
    Thu Nov 14 12:23:33 2019 CAWA_I_20007 Environment variable: Path=C:\CA\WA_Agent_R11_3_4\jre\bin\;C:\CA\WA_Agent_R11_3_4\jre\bin\server;C:\CA\WA_Agent_R11_3_4\addons;C:\CA\WA_Agent_R11_3_4\addons;C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\wbin;C:\Program Files (x86)\RSA SecurID Token Common;C:\Program Files\RSA SecurID Token Common;C:\Program Files (x86)\Common Files\Oracle\Java\javapath;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;C:\Program Files (x86)\Microsoft SQL Server\Client SDK\ODBC\130\Tools\Binn\;C:\Program Files (x86)\Microsoft SQL Server\140\Tools\Binn\;C:\Program Files (x86)\Microsoft SQL Server\140\DTS\Binn\;C:\Program Files (x86)\Microsoft SQL Server\140\Tools\Binn\ManagementStudio\;C:\Program Files (x86)\SecureCRT\;C:\WINDOWS\system32\config\systemprofile\AppData\Local\Microsoft\WindowsApps
    Thu Nov 14 12:23:33 2019 CAWA_I_20007 Environment variable: PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
    Thu Nov 14 12:23:33 2019 CAWA_I_20007 Environment variable: PROCESSOR_ARCHITECTURE=AMD64
    Thu Nov 14 12:23:33 2019 CAWA_I_20007 Environment variable: PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 142 Stepping 9, GenuineIntel
    Thu Nov 14 12:23:34 2019 CAWA_I_20007 Environment variable: PROCESSOR_LEVEL=6
    Thu Nov 14 12:23:34 2019 CAWA_I_20007 Environment variable: PROCESSOR_REVISION=8e09
    Thu Nov 14 12:23:34 2019 CAWA_I_20007 Environment variable: ProgramData=C:\ProgramData
    Thu Nov 14 12:23:34 2019 CAWA_I_20007 Environment variable: ProgramFiles=C:\Program Files
    Thu Nov 14 12:23:34 2019 CAWA_I_20007 Environment variable: ProgramFiles(x86)=C:\Program Files (x86)
    Thu Nov 14 12:23:34 2019 CAWA_I_20007 Environment variable: ProgramW6432=C:\Program Files
    Thu Nov 14 12:23:34 2019 CAWA_I_20007 Environment variable: PSModulePath=C:\Program Files\WindowsPowerShell\Modules;C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules
    Thu Nov 14 12:23:34 2019 CAWA_I_20007 Environment variable: PUBLIC=C:\Users\Public
    Thu Nov 14 12:23:34 2019 CAWA_I_20007 Environment variable: SystemDrive=C:
    Thu Nov 14 12:23:34 2019 CAWA_I_20007 Environment variable: SystemRoot=C:\WINDOWS
    Thu Nov 14 12:23:34 2019 CAWA_I_20007 Environment variable: TEMP=C:\WINDOWS\TEMP
    Thu Nov 14 12:23:34 2019 CAWA_I_20007 Environment variable: TMP=C:\WINDOWS\TEMP
    Thu Nov 14 12:23:34 2019 CAWA_I_20007 Environment variable: UATDATA=C:\WINDOWS\CCM\UATData\D9F8C395-CAB8-491d-B8AC-179A1FE1BE77
    Thu Nov 14 12:23:34 2019 CAWA_I_20007 Environment variable: USERDOMAIN=HEBMTY
    Thu Nov 14 12:23:34 2019 CAWA_I_20007 Environment variable: USERNAME=MXVADM_MX02689$
    Thu Nov 14 12:23:34 2019 CAWA_I_20007 Environment variable: USERPROFILE=C:\WINDOWS\system32\config\systemprofile
    Thu Nov 14 12:23:34 2019 CAWA_I_20007 Environment variable: windir=C:\WINDOWS
    Thu Nov 14 12:23:34 2019 CAWA_I_20013 Command to be executed: "C:\WINDOWS\SYSTEM32\cmd.exe" /c C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -command "D:/helloworld.ps1" >>"C:\CA\WA_Agent_R11_3_4\spool\CENTRAL_MANAGER\MAIN\01_PRUEBA_RUBEN.49\1313262448_HEBER_HELLOPOWER" 2>>&1
    Thu Nov 14 12:23:34 2019 CAWA_I_20010 The local security is bypassed
    Thu Nov 14 12:23:34 2019 CAWA_I_20022 Process created with pid: 7828
    Thu Nov 14 12:23:34 2019 CAWA_I_20017 Job completed successfully. Exit code 0

    in the log it says it ran succesfully but it doesn't do anything :( I seriously been struggling with this over 2 weeks or more I don't know what could cause this issue




  • 19.  RE: plumbing windows jobs to powershell files

    Posted 11-15-2019 10:10 AM
    Hi Heber.  I'm wondering what your ps script looks like.  Does it use this form of referencing any file in the directory you are already in?...

    .\myfile.txt

    My understanding is that .\ is like a ps wild card that basically is a shorthand for "the directory i'm currently in".

    If you have such a reference in your ps script , its possible that when you execute powershell directly using the ise, that the perceived current directory is where your ps script is and that's a desired behavior.  But when you execute it from ca, its where the powershell exe is located and not only is that undesirable but the user acct being used in ca doesn't even have permissions to write etc in the windows directory where the ps exec is.  And perhaps that is causing a mystery.  When I saw this happening to me I qualified the path to myfile and all was good.

    This is just a shot in the dark based on a mistake I was making as I started getting used to this.  At this time I don't know anything about the ca log files.



  • 20.  RE: plumbing windows jobs to powershell files

    Posted 11-15-2019 10:17 AM
    Hi Stan no, in fact im giving the entire directory address like C:/Users/ etc etc etc :(


  • 21.  RE: plumbing windows jobs to powershell files

    Posted 11-15-2019 12:41 PM
    ok, the frustration sounded so familiar that I felt like it might help to share.​


  • 22.  RE: plumbing windows jobs to powershell files

    Posted 11-08-2019 12:51 PM
    Edited by stan teitelbaum 11-08-2019 01:49 PM
    we seem to be getting there.  In our work session we found that invoke-sqlcmd needed to be installed before we could even exec the script on the server where the agent runs.  And while our ca contact/peer felt that the permissions we gave the non expiring userid there was more than necessary, we did get the script to run under that userid's creds.

    we think also that because we have spaces in the path to the ps1 file that this pattern (notice escape before double quote)  needs to be in the ​arguments to pass:

    -command \ "E:\x\y y\z\a\b.ps1\"

    I don't know yet if the last slash was a typo on my part or placed there by the person who knew that to get past one error on the ca client we needed the escape sequence pattern.  I'm looking into that but I did remove it temporarily, ran and still no luck..

    I'm asking my peer to give the userid exec on folder x.  That way I can try to run with this argument and see what happens -command "E:\x\b.ps1" .

    Any search engine based url I try to use on this subject that starts with docops.ca.com... seems to be returning an error so my attempts thus far to find an answer online are failing.  I may try this from home this eve.

    In anticipation of a couple more hurdles I put logging into the script as shown below.  The idea is that we at least need to know if the ps1 script is starting up and then if it is what errors are being generated.  Right now, triggering the event is running on the client but doing nothing over on the agent server.  Every now and then I look over at the sql server to see if its even aware that something is trying to run something else over there.  The catch block hasn't happened so I don't know if that clause will work when we need it to.

    Out-File -FilePath .\Script.txt -InputObject "before" -Append
    try
    {
    $SQLServer = "someserver"
    $Database = "MSDB"
    $ExecAgent = "exec dbo.sp_start_job N'test ca series d to ssis'"
    Invoke-Sqlcmd -ServerInstance $SQLServer -Database $Database -Query $ExecAgent
    }
    catch
    {
    Out-File -FilePath .\Script.txt -InputObject $_.Message
    }
    Out-File -FilePath .\Script.txt -InputObject "after" -Append





  • 23.  RE: plumbing windows jobs to powershell files

    Posted 11-08-2019 03:26 PM
    we got this to work by putting an underscore in the folder name that has a blank.  And going with Andy's original format.

    I didn't realize that if you don't upload a change in the ca client, triggering a test will fool a newbie like me.  Still anxious to hear how blanks are dealt with in passed file name arguments but we are on a roll.​  thank you!


  • 24.  RE: plumbing windows jobs to powershell files

    Posted 11-18-2019 02:19 PM
    Can't count the number I've forgotten to upload the application after making a few changes.  You get used to it.  I would also suggest using the simulation feature a lot.  I've made a lot of 'simple' or 'quick' changes to the a schedule that have failed because I didn't simulate the change after uploading it.  Now I sim everything to double check my work.

    I've avoided spaces in file names for so long I'm not sure we have any arguments with spaces being passed.  If I run into any I'll get back to you with our argument format.

    ------------------------------
    Andy Reimer
    ------------------------------



  • 25.  RE: plumbing windows jobs to powershell files

    Posted 11-19-2019 07:31 AM
    how can I give both Andy and Sharon kudos?  Sharon answered the original question which took so many turns I lost track of it till just now when I was marking Andy's answer as the "best answer".  I'd like to give Sharon best answer also.​


  • 26.  RE: plumbing windows jobs to powershell files

    Posted 11-19-2019 08:30 AM
    Hello Stan,

    You can only mark 1 as best answer, but you can recommend both.

    Thanks

    ------------------------------
    Diane Craddock
    Community Manager, Broadcom Enterprise Software Division
    Broadcom Inc.
    ------------------------------