Child pages
  • PowerShell Plugin
Skip to end of metadata
Go to start of metadata

Plugin Information

View PowerShell on the plugin site for more information.

Integrates with Windows PowerShell by allowing you to directly write PowerShell scripts into the text box in Jenkins. Other than that, this plugin works pretty much like the standard shell script support.


Version 1.3 (Sept 18 2015)

  • PowerShell now runs in Non-Interactive mode to prevent interactive prompts from hanging the build
  • PowerShell now runs with ExcecutionPolicy set to "Bypass" to avoid execution policy issues
  • Scripts now exit with $LastExitCode, causing non-zero exit codes to mark a build as failed
  • Added help and list of available environment variables (including English and French translations)

Version 1.2 (Aug 5 2009)

  • Fixed a quotation problem.

Version 1.1 (July 1 2009)

  • Fixed a bug in the launch of PowerShell (patch)

Version 1.0 (June 16 2009)

  • Initial version


  1. The default execution policy of PowerShell seems to be Restricted, meaning it won't run any script files (it is restricted to just an interactive command console). But the PowerShell plugin creates a temp file (e.g. "hudson3492366779710559401.ps1") with the script content from the Job's configuration and then attempts to run it through powershell.exe. How does this mesh with that default execution policy? One option is to liberalize the execution policy (e.g. Set-ExecutionPolicy Unrestricted), but that is rather loose, applying to any script file. Is this what everyone else is doing?

    1. The normal way woul be to set your policy to RemoteSigned. This will allow you to execute any local script and any remote script if it's signed in a trusted fashion.  So no need to open the door completely by setting to Unrestricted (smile)

      Now if this is still a problem I could investigate in signing the generated ps1 file such that thing could work with AllSigned as policy. Though that will anyhow require specifying and registering a valid trusted cert for signing.

      What might however do the trick also is letting you specify a ps1 file for yourself, such that your file gets executed. I was planning to add this extension anyhow. Perhaps I may find time to add this somewhere this week.

  2. The PowerShell plugin fails for me unless I first execute 'Set-ExecutionPolicy remotesigned' in a PowerShell window. This is messy and also won't be adequate when Hudson runs as a service.

    Wim wrote:

    > The normal way would be to set your policy to RemoteSigned.

    How do I do this please?

    Could the plugin not do this when it invokes the Hudson generated script (e.g. PowerShell -ExecutionPolicy remotesigned hudson3492366779710559401.ps1) ?

  3. Unknown User (

    good plugin, but it has a big downfall: no return value. Even if the build fails, Hudson doesn't seem to recognize it and says everything is fine. So I switched back to Batch-Scripts with a command like " powershell.exe "& 'script.ps1'" "

    1. Unknown User (jamiet)

      Same problem here. If Hudson doesn't know that the build fails then that's a big problem. I'm going to try Michael's batch-script-wrapper technique!

  4. Unknown User (

    How can I pass arguments while calling a powershell script?

  5. Unknown User (jamiet)

    Hello folks,

    I'm having issue with ExecutionPolicy too. I have opened up the Powershell console as the same user that is running the Hudson service and issued "Set-ExecutionPolicy unrestricted". However, I'm still getting the following when executing any Powershell command from the build step:

    File C:\DOCUME~1\SVC_PR~1\LOCALS~1\Temp\hudson6647546035708680215.ps1 cannot be loaded because the execution of scripts is disabled on this system

    How do I tell Hudson to always run Powershell scripts with ExecutionPolicy="Unrestricted" (or RemoteSigned, whatever)?

    Thank you in advance!


    1. Unknown User (jamiet)


      Installing Powershell v2 solved this problem. I have no idea why! but frankly don't care either :)


      1. Hi Jamie

        As I understand it, PowerShell v2 has solved the execution policy problem for you.

        What about the issue of not returning a pass/fail value? Is that still a problem?


        1. Unknown User (jamiet)

          Nope, happy to say we solved that one too. At the end of the POSH script we have the following:

          exit $LastExitCode

          Easy when you know how! Hope this is useful to others.

      2. Unknown User (epowers)

        I actually found that simply installing v2 did not solve the execution problem.  I had to use set-executionpolicy RemoteSigned for it to work, but it now works.

    2. Unknown User (

      I've had the problem with the temp powershell script "cannot be loaded because the execution of scripts is disabled on this system".

      In my case, I already had Powershell 2 as I was on windows 7, but it was 64bit windows 7, and somebody installed the 32 bit version of Java to run hudson under (as they were used to working on XP). 32 bit Java can only run 32 bit batch shell's and powershell shell's.

      After uninstalling 32bit java, and installing 64 bit java, Hudson kicked off 64 bit batch and powershell shells and worked fine.

      You can check if you are in a 32 bit shell like this:

      • PowerShell run “Write $PSHome” and if you have a Wow64 directory in the path, you are in a 32 bit process
      • In command shell run “echo %programfiles%” and if the program files directory has (x86) in it, you are in a 32 bit process

      Hopefully that helps someone else.

      I still can't work out how to pass parameters to powershell scripts using this plugin. If I call this:

       .\Scripts\Deploy.ps1 -Environment tst

      The parameter tst is not found.

      Has anyone else worked out how to do that? (I can of course wrap powershell using a batch script like others have suggested, but I wanted to try using this plugin)

      1. Unknown User (cynic783)

        Sometimes you might want to use 32-bit Java on a 64-bit system, for example if you are calling 32-bit native code from Java.

        In that case, you can use the PowerShell (x86), which is installed side-by-side with 64-bit version.

        You need to set execution policy separately for x86 and 64-bit.


      2. D Z

        How exactly did you accomplish this? I have only 64bit java installed, and yet Jenkins is still spawning 32bit command windows. Where is this configured?

  6. Sorry if this is slightly off topic, but I'm also using a 64-bit Windows 7 and also getting the 32bit PowerShell :(

    There was no Java installed when I installed Jenkins (perhaps my first mistake)

    I've now installed both 32 and 64 bit JREs, but I cannot find a setting in Jenkins to tell it which to use.

    Is replacing the JRE subfolder in Jenkins with the 64bit version of the JRE the right thing to do ?

    1. D Z

      Were you able to figure this out? I'm running into the same problem and can't seem to solve it.

    2. D Z

      I did as you suggested here and replaced the JRE subfolder of Jenkins with the 64bit version and it worked.

      However, I don't know if this is a permenant solution. Won't Jenkins try to reinstall the version of Java it thinks it should install at some point?...

  7. I patched the plugin to make it bypass the execution policy (and fail when the script contains errors). The patch and an .hpi are attached to It works for me, but it would be nice if a few other people would test this.

  8. If you go to "Manage Jenkins" > "System Properties" and look for the '' (this will say 64bit version if jenkins is running as x64. And 'os.arch' (Operating system architecture) will tell you the OS architecture. 

    I wouldnt replace the JRE folder, I don't know what side efffects that may or may not have, or what other apps on your computer it may break.

    Basically to make it use the 64bit version, you need to start java.exe 64bit version. So you need to adjust whatever you startup commands are to use the right JRE/JDK bin directory. 

    I'm not sure what comes with the windows installable version of Jenkins these days, but early on it was the 32bit version. Its actually very easy to use the war version on windows, just download whichever version of java, and then download the war file, then startup jenkins on the command line using java -jar jenkins.war (setting whatever other parameters you would like to pass into it (see this page for more options )

    So, if you: 

    • Install perfered version of java
    • Set it as JAVA_HOME system variable on windows (or use the full path to java.exe if you don't wan't it as a environment variable)
    • Run the java -jar jenkins.war command to start it up (with whatever other start up options you want)
    • Then install as windows service from within the jenkins 'Manage Jenkins' section

    You should have Jenkins working on whatever java version you want. 

    Once up and running, you can check if you are in a 32 bit shell like this:

    • PowerShell run “Write $PSHome” and if you have a Wow64 directory in the path, you are in a 32 bit process
    • In command shell run “echo %programfiles%” and if the program files directory has (x86) in it, you are in a 32 bit process

    I have also found power shell output being cut off by the 'virtual console output size' in powershell. This command can adjust it, run this as the first line of you power shell script. 

    Get$Host.UI.RawUI.BufferSize = New-Object Management.Automation.Host.Size (500, 25)

    I've never had to run both 32bit and 64 bit process's, however I believe if you run Jenkins as x64, you should be able to run 32bit exe's by calling them directly (so you don't get their x64 equivalent). 

    1. D Z

      Thank you Brian. I've forwarded your comments to our team and if we come up with any solutions I'll respond here.

    2. D Z

      I'll say this much: The "Manage Jenkins" > "System Information" > "" is the JRE that is running in the jre folder under C:\Program Files (x86)\Jenkins\jre\

      It may be that when you install Jenkins as a Windows service, that if it is installed as 32bit, that you can't change that unless you reinstall the Windows Service. I'll have to play around and test some more to see...

  9. There is an obnoxious "bug" with this plugin. If I have an issue with my powershell script and fail to provide a required parameter, it will hang waiting for user input to provide the required parameter. The very trivial fix would be to execute powershell with the -noninteractive, which would cause this to be reported as an error and therefor fail my build with a meaningful error message rather than just hanging indefinitely with no suggestion as to what is going on.

    Additionally, it should be possible to make it configurable (like the MSbuild plugin) to choose between 32 and 64 bit versions of powershell, which was an issue for a different part of my build process, which I worked around with a somewhat hack solution.

    1. PowerShell is now executed with the -NonInteractive switch

  10. I have installed the plugin and am trying to create a variable as part of a powercli script, then access the value in a Windows Batch Command step.  I have tried lots of things, but can't seem to make this work.  Is it possible?

    In 'Execute Windows Batch Command' task, I have this:

    echo myY should show a value here : %myY%

    Value doesn't show up.  Anyone see what I am doing wrong?

    1. I was thinking of trying this myself but I doubt it will work.  Jenkins is probably starting the PowerShell process with a copy of the environment so anything you do in that environment will not be seen in the launching process.  This is pretty normal and it is what lets the 'child' processes muck around with things like the PATH without screwing up the 'parent'.  All the children get a copy and can change the PATH all they want without breaking the invoker.

      I do have the same need to pass information back from the PowerShell script however.  I know this is a hack, but the only two things I can think of are 1) write something to a well known key in the registry and 2) write something to a well known log file and pull the results from there.

      I will post back what I hack together if you are interested (and I can get it working).

  11. I have powershell version 3.0 installed and when I try to run a powershell command or script, i still get the same error.

    & : File C:\windows\TEMP\hudson5041614610100256691.ps1 cannot be loaded 
    because running scripts is disabled on this system.
    & : File C:\windows\TEMP\hudson5041614610100256691.ps1 cannot be loaded  because running scripts is disabled on this system.

    what is the workaround and Is this error addressed in version 3.0 ?

    1. try setting the execution policy in the x86 version of Powershell :)

  12. Error:  File C:\WINDOWS\TEMP\hudson2202497609195961964.ps1 cannot be loaded because running scripts is disabled on this system. 

    I had already launched my Powershell and set the execution policy to RemoteSigned and still received this error.  Jenkins launches the x86 version of Powershell.  I suspected that I needed to launch the x86 version of Powershell and set the execution policy there too!   


    Solution:  Launch the x86 version of Powershell (as Administrator) C:\Windows\SysWOW64\WindowsPowerShell\v1.0\Powershell.exe  and set the execution policy there as well (set-executionpolicy RemoteSigned)

    Hope this helps!

    1. I ran the execution policy as admin and still got the same error.  I found a patch for this.

  13. s g

    Current LastExitCode support is not full.

    return command + "\r\nexit $LastExitCode";


    powershell -NoProfile -ExecutionPolicy unrestricted -Command "try{ & { .\make.ps1

     } } finally { if ($LASTEXITCODE)

    Unknown macro: {write-host "ERRORs}


    If there is syntax error in .\make.ps1, 'if ($LASTEXITCODE)' part skipped, but powershell self exits with 1.

  14. So I have V1.3 installed, but I still always get an exit code of 0 regardless of success or failure

  15. Ah... my scripts are not in fact using LastExitCode. So something is wrong in this plugin.

    I have the workaround of adding ;$LASTEXITCODE but who wants to do that when calling multiple scripts.


  16. Is there an easy way to use the x64 PowerShell instance? It's using the x86 by default. It'd nice to have an option to change the engine.

  17. Powershell plugin not supporting Credential object.But the windows powershell does.

    How to rectify the below error.



    Rename-Item : Cannot retrieve the dynamic parameters for the cmdlet. The provid
    er does not support the use of credentials. Perform the operation again without
    specifying credentials.
    At C:\Windows\TEMP\hudson6249932248540013738.ps1:4 char:12
    + rename-item <<<< -path $env:warFilesFolder -newname $env:warFilesFolder+$((g
    et-date).toString() -replace " ","_" -replace ":","-") -Credential $credential
    + CategoryInfo : InvalidArgument: (:) [Rename-Item], ParameterBin
    + FullyQualifiedErrorId : GetDynamicParametersException,Microsoft.PowerShe

  18. Total time: 31 seconds
    [MartServer] $ powershell.exe -NonInteractive -ExecutionPolicy ByPass "& 'C:\Windows\TEMP\hudson3864988451562351881.ps1'"
    The provider does not support the use of credentials. Perform the operation aga
    in without specifying credentials.
    At C:\Windows\TEMP\hudson3864988451562351881.ps1:4 char:1
    + <<<< new-psdrive -name "N" -Root "\\win-el6hnngkvjo\c$\Git\Mart Remaining Fi
    les" -PSProvider "FileSystem" -Credential $credential
    + CategoryInfo : NotImplemented: (:) [], PSNotSupportedException
    + FullyQualifiedErrorId : NotSupported

  19. any idea how to get past this issue with the powershell command?
    & : The term 'C:\Windows\System32\bash.exe' 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 
  20. I'd like to have a "secure" switch which:

    • Doesn't use -ExecutionPolicy Bypass 
    • And doesn't append "exit $LastExitCode" to the script.

    The reason being that this allows for use in a secure environment that enforces script signing. Previously this wasn't a big deal but since PowerShell 5 where you can audit scripts run with Bypass, and otherwise prevent their execution, it would be good.

  21. I was able to run the following, before installing this plugin. So what functionality does this plugin give me that I don't have with Jenkins by default? Thanks

    pipeline {
        agent any
        stages {
            stage ('Test PS') {
                steps {
                    script {
                        powershell 'Write-Output "Hello, World!" '


    1. I assume here is the description -

      Unfortunately, plugin does not work (I tried it in jenkins 2.107.2). So, thank you for hint on how to use it without plugin.

Write a comment…