I'm having a strange scenario where my command works on PowerShell manually but not when executed on Jenkins PowerShell plugin. I'm new to PowerShell and Jenkins and I'm thinking that there's a rule I'm missing. I looked all over the here and net but I failed to find the solution.
I created a job that executes a PowerShell script that opens an RDP file on my desktop using a freestyle project. It works as expected when executed on Powershell but in Jenkins, the build succeeds but it did not open the RDP.
Here's the script:
Start-Process "$env:windir\system32\mstsc.exe" -ArgumentList "RDP File /h:900 /w:1600" -WindowStyle Minimized
I'm using Windows Server 2016.
Here's what I tried:
By default Jenkins uses 32-bit PowerShell, so I manually used the 64-bit but it didn't work.
I made sure that Get-ExecutionPolicy is set to RemoteSigned on LocalMachine
Run the script using Windows Batch Command
I tried opening notepad but it does not work too.
Is this really the behavior of the PowerShell plugin? Is there any points that I'm missing? Kindly help me with this.
To anyone might need this. I was able to execute the RDP via Jenkins PowerShell plugin.
What I did was to go Jenkins' Window Service > Log on tab > Select "This account" and enter your user account credentials.
I suspect this is a security issue. Jenkins by default is using the "SYSTEM" account which does not have enough privileges.
I'm Running powershell script using TFS build step - Run PowerShell on Target Machines but it does not work.
Here's how script looks like:
Start-Process -FilePath 'Bginfo.lnk'
It runs shurtcut that refreshes information on pc desktop using bginfo.exe - script works fine when its executed manualy.
TFS executes that script, but it does not work - bginfo is not refreshed.
If I add to that script line that creates new file it also will be created.
Why it does not automatically update background using specified shurtcut?
I can reproduce this issue. Tried command line, batch script, PowerShell steps with /TIMER:0 /SILENT /NOLICPROMPT set and with the service account which has administrator's privilege. Seems it only works when run the script manually on target machine.
In this case, if you want to refresh the system info automatically, you can use task schedule to run the Bginfo script in target machine. Reference below threads :
BGinfo not running silently
BGInfo on Windows Server 2012
Making BgInfo work in Windows 2012 / Windows 2016
Through a PowerShell script, I'm trying to interact with SCCM 2012 R2 Task Sequences. A lot of sites refer to using something similar to the following:
$tsenv = new-object -ComObject microsoft.sms.tsenvironment
First, if there is a better/different way, I'm totally open to it. But for this way, whenever I run that line, regardless of how I loaded the ConfigurationManager module (e.g. launch PowerShell from SCCM console, load the ConfigurationManager.psd1 from an x86 or x64 PowerShell console), it always returns the error below. I've also tried this on lab SCCM 2012 R2 environments and 2 separate production environments:
"New-Object : Retrieving the COM class factory for component with CLSID ... failed due to the following error: 80040154 Class not registered"
I'm coming up short searching for answers online, so hoping someone here is able to use that ComObject in PowerShell with SCCM 2012 R2 or if I'm just out of luck.
FYI,
In addition to having an active task sequence, you should also make sure that you are running from x64 process when creating the object when running on 64-bit OS, o/w the creation will fail with the 'Class not registered' error as if there is no TS running.
I have a windows update module which I copy over into the Module directory for PS. however, even with the Set-ExecutionPolicy unrestricted command issued, when i try to execute the .ps1 file, I get an error stating that the it's not digitally signed and will not run.
I was under the impression that if you set the exection policy to 'unrestricted' that you don't need to have scripts 'signed' in order to run.
Is there something else that I need to do in the Windows 2008 R2 environment?
Thanks.
Make sure the script is not blocked. Check if the script's properties page contains an 'Unblock' button. If so, click it to unblock the file.
Since this question continues to attract responses that are either
refuted by the question body or don't address the actual problem,
please read this simple summary of what you need to know:
This is not a "Why won't my default installation of PowerShell run scripts?" question.
This is not a "Why won't my installation of PowerShell run scripts downloaded from the internet?" question.
The question is why the RemoteSigned execution policy is preventing script execution when it shouldn't.
RemoteSigned is the only execution policy I want to use. I am aware that other, less-restrictive policies are available. If
those policies were acceptable substitutes I would have just used them
instead and this question wouldn't exist.
The execution policy is already set to RemoteSigned. Changing it from RemoteSigned to RemoteSigned is not a solution.
The script file is created and stored locally.
The script file is not blocked. The script file was never blocked (see previous point).
The script file cannot be unblocked because there is nothing to unblock (see previous point).
The script file is (attempted to be) executed by an administrator.
Windows PowerShell is the only application involved. Not Windows PowerShell ISE nor Command Prompt nor any other tools or
editors are relevant.
The cause of the problem has already been identified (see accepted answer). After nearly 8 years, I think all other obvious
explanations, whether applicable or not, have been posted, too. If
you think otherwise then please read the question and existing
answers in their entirety before adding yours.
I am using Windows PowerShell 2.0 on 64-bit Windows 7 Professional. I have a script on my Desktop that causes the following error when I try to run it:
File C:\Users\UserName\Desktop\Script.ps1 cannot be loaded. The file C:\Users\UserName\Desktop\Script.ps1 is not digitally signed. The script will not execute on the system. Please see "get-help about_signing" for more details..
At line:1 char:54
+ C:\Users\UserName\Desktop\TestGetWindowsUpdateLog.ps1 <<<<
+ CategoryInfo : NotSpecified: (:) [], PSSecurityException
+ FullyQualifiedErrorId : RuntimeException
I am both a domain administrator and a local administrator, and if I run Get-ExecutionPolicy -List, I can see that the Group Policy Object I created to configure PowerShell is correctly applying the RemoteSigned execution policy at the machine level:
Scope ExecutionPolicy
----- ---------------
MachinePolicy RemoteSigned
UserPolicy Undefined
Process Undefined
CurrentUser Undefined
LocalMachine Undefined
I created the script myself in Notepad, and used the Sysinternals' streams utility and the file Properties dialog to confirm that the script is not being treated as having come from the internet. If I copy the script to a network share on a domain server, then it's allowed to execute. If I run Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope LocalMachine then the local script is still not allowed to execute, which makes sense since the execution policy at the MachinePolicy scope will take precedence.
As documented by about_Execution_Policies(current; at time of question), the RemoteSigned policy means:
Scripts can run.
Requires a digital signature from a trusted publisher on scripts and configuration files that are downloaded from the Internet
(including e-mail and instant messaging programs).
Does not require digital signatures on scripts that you have run and that you have written on the local computer (not downloaded from
the Internet).
Risks running unsigned scripts from sources other than the Internet and signed, but malicious, scripts.
My script is not signed, but since it is both created and executed locally, it should satisfy the third bullet point above. Therefore...
Why is my script not being allowed to run?
Why does PowerShell complain that my script "is not digitally signed" when that requirement should only apply to files from the Internet?
Why does PowerShell no longer care about the script not being signed when it's run from a network share?
Some things to check:
Can you change to unrestricted?
Set-ExecutionPolicy Unrestricted
Is the group policy set?
Computer Configuration\Administrative Templates\Windows Components\Windows PowerShell
User Configuration\Administrative Templates\Windows Components\Windows PowerShell
Also, how are you calling Script.ps1?
Does this allow it to run?
powershell.exe -executionpolicy bypass -file .\Script.ps1
Is the file being blocked? I had the same issue and was able to resolve it by right clicking the .PS1 file, Properties and choosing Unblock.
When you run a .ps1 PowerShell script you might get the message saying “.ps1 is not digitally signed. The script will not execute on the system.”
To fix it you have to run the command below to run Set-ExecutionPolicy and change the Execution Policy setting.
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
I have found out when running a PS1 file for a Mapped drive to Dropbox that I'm always getting this error. When opening up properties for the PS1 there is no "Unblock".
The only thing that work for me is
powershell.exe -executionpolicy bypass -file .\Script.ps1
I finally tracked this down to .NET Code Access Security. I have some internally-developed binary modules that are stored on and executed from a network share. To get .NET 2.0/PowerShell 2.0 to load them, I had added a URL rule to the Intranet code group to trust that directory:
PS> & "$Env:SystemRoot\Microsoft.NET\Framework64\v2.0.50727\caspol.exe" -machine -listgroups
Microsoft (R) .NET Framework CasPol 2.0.50727.5420
Copyright (c) Microsoft Corporation. All rights reserved.
Security is ON
Execution checking is ON
Policy change prompt is ON
Level = Machine
Code Groups:
1. All code: Nothing
1.1. Zone - MyComputer: FullTrust
1.1.1. StrongName - ...: FullTrust
1.1.2. StrongName - ...: FullTrust
1.2. Zone - Intranet: LocalIntranet
1.2.1. All code: Same site Web
1.2.2. All code: Same directory FileIO - 'Read, PathDiscovery'
1.2.3. Url - file://Server/Share/Directory/WindowsPowerShell/Modules/*: FullTrust
1.3. Zone - Internet: Internet
1.3.1. All code: Same site Web
1.4. Zone - Untrusted: Nothing
1.5. Zone - Trusted: Internet
1.5.1. All code: Same site Web
Note that, depending on which versions of .NET are installed and whether it's 32- or 64-bit Windows, caspol.exe can exist in the following locations, each with their own security configuration (security.config):
$Env:SystemRoot\Microsoft.NET\Framework\v2.0.50727\
$Env:SystemRoot\Microsoft.NET\Framework64\v2.0.50727\
$Env:SystemRoot\Microsoft.NET\Framework\v4.0.30319\
$Env:SystemRoot\Microsoft.NET\Framework64\v4.0.30319\
After deleting group 1.2.3....
PS> & "$Env:SystemRoot\Microsoft.NET\Framework64\v2.0.50727\caspol.exe" -machine -remgroup 1.2.3.
Microsoft (R) .NET Framework CasPol 2.0.50727.9136
Copyright (c) Microsoft Corporation. All rights reserved.
The operation you are performing will alter security policy.
Are you sure you want to perform this operation? (yes/no)
yes
Removed code group from the Machine level.
Success
...I am left with the default CAS configuration and local scripts now work again. It's been a while since I've tinkered with CAS, and I'm not sure why my rule would seem to interfere with those granting FullTrust to MyComputer, but since CAS is deprecated as of .NET 4.0 (on which PowerShell 3.0 is based), I guess it's a moot point now.
If the file is copied from a network location, that is, another computer, Windows might have blocked that file. Right click on the file and click on the unblock button and see if it works.
What works for me was right-click on the .ps1 file and then properties. Click the "UNBLOCK" button. Works great fir me after spending hours trying to change the policies.
Select your terminal Command prompt instead of Power shell. That should work.
This is an IDE issue. Change the setting in the PowerShell GUI. Go to the Tools tab and select Options, and then Debugging options. Then check the box Turn off requirement for scripts to be signed. Done.
Please make a backup for the script.bs1 file
What works for me was deleting the script.bs1 file and running the execution command.
I was having the same issue and fixed it by changing the default program to open .ps1 files to PowerShell. It was set to Notepad.
Try running the Powershell GUI as Administrator
This occurs due to Powershell execution policy is set to restricted by default which prevents execution PowerShell scripts and protects from running malicious scripts.
You can change execution scope for specific scope by running the following command
Set-ExecutionPolicy -Scope Process
Run below 2 commands in PowerShell window
Set-ExecutionPolicy unrestricted
Unblock-File -Path D:\PowerShell\Script.ps1