I have created a package in SCCM 2012 that should deploy and run a powershell script. I have looked at a previous post on here Other Post but there wasn't any information.
In the Program Command Line, I have the following command:
powershell.exe -ExecutionPolicy Bypass -force -WindowStyle Hidden .\PowershellUpdateScript.ps1
I am targeting a test group and setting it to deploy immediately however when I check the deployment status, it shows as status "In Progress" and Description "Received". It has been that way for over 2 hours. I am not sure where the issue is.
I know that the Scripts feature is there and super convenient but the client powershell version needs to be a minimum version 3. The irony is that this package will update client powershell versions.
Any suggestions or advise would be greatly appreciated.
Since you are updating the powershell version, instead of using a powershell script you should download the MS update package for the version of powershell.
You can then use the wusa.exe command to deploy the update. Then use this ps command as a detection method
Get-WmiObject Win32_QuickFixEngineering -filter "HotFixID='KB#######'"
Related
I'm trying to schedule a powershell script to run on a server. I used $env:PSModulePath and one of the powershell locations is c:\windows\system32\windowsPowerShell\v1.0\Modules. When I look in that location, there is no Powershell.exe there. I wanted to use that for the Application name in the system scheduler. How can I verify that Powershell.exe is there? I also wanted to find which version each one is for all of the powershell versions seen with $env command above to verify which would be the 5.1 version that I tested on my computer with.
env:PSModulePath
c:\windows\system32\windowsPowerShell\v1.0\Modules is the Modules directory
$psHome returns the .exe location
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.
When using PowerShell ISE with Chocolatey to install applications, if I forget the -y switch, it hangs waiting on some sort of "confirmation" that's not popping up anywhere?
I have to Ctrl+Alt+Del to kill PowerShell ISE and Chocolatey and it leaves things in half-way state.
This is what it looks like below:
In addition to the comments to the OP above, regarding PowerShell ISE not supporting (most) interactive console applications...
It is worth remembering that the REPL window in PowerShell_ISE.exe is not just some sort of docked PowerShell.exe console. Most of the time the user experience is the same, but this hides a number of differences:
https://blogs.msdn.microsoft.com/powershell/2009/04/17/differences-between-the-ise-and-powershell-console/
Both these executables are host applications that run a PowerShell runspace (engine). You can even write your own application that "hosts" PowerShell. It is the host application that determines the user experience.
PowerShell.org: The Shell vs The host
Spiceworks.com: The Shell vs The Host
Writing a Windows PowerShell Host
And finally, for the most curious:
How PowerShell works
I think I wrote this answer more for my own benefit; it's a useful refresher for me as I get asked this by colleagues every now and again...
It's simply because PoSH ISE is not a thing to use for user interactive .exe commands.
If you .exe or whatever expects a response, when in the ISE you have to provide it.
You can easily prove this is not a Chocolatey thing by trying any other .exe that kicks out interactive stuff. For example, just type:
nslookup in the script pane and F8 to run it, or type it in the console pane and hit enter
Either way, the console will just hang, waiting for a interactive response that you cannot provide.
You can still use interactive commands like nslookup in the PoSH ISE, but you have to provide all parameters. For example:
nslookup microsoft.com
nslookup -type=mx microsoft.com
nslookup -q=soa microsoft.com
PS 5.1 even kicks out an error message now.
nslookup
Cannot start "nslookup". Interactive console applications are not supported.
To run the application, use the Start-Process cmdlet or use "Start PowerShell.exe" from the File menu.
To view/modify the list of blocked console applications, use $psUnsupportedConsoleApplications, or consult online help.
At line:0 char:0
You can easily shell out to the PowerShell console host temporarily this way.
Here is a function I have in my profile for such efforts.
Function Start-ConsoleCommand
{
[CmdletBinding()]
[Alias('scc')]
Param
(
[string]$ConsoleCommand,
[switch]$PoSHCore
)
If ($PoSHCore)
{Start-Process pwsh -ArgumentList "-NoExit","-Command &{ $ConsoleCommand }" -Wait}
Else
{Start-Process powershell -ArgumentList "-NoExit","-Command &{ $ConsoleCommand }" -Wait}
}
So, just type
scc -ConsoleCommand choco install winmerge
It'll pop the console host and stay open until you close it.
Update
As per request of - Alex Kwitny
PoSHGet default has only two repositories,
nuget
PSGallery
but you can add your own or another.
You use the below cmdlets to make this happen.
I have not had to use Chocolatey in a while, but taking a quick look and my archives, the below is what I used
Set up chocolatey repository
Find-Module
Get-Module
Find-Package
Get-Package
Get-PackageProvider
Get-PackageSource
Get-PackageSource -Provider chocolatey
Register-PackageSource -Name chocolatey -Provider Chocolatey -Trusted -Location http://chocolatey.org/api/v2/ -Verbose
Find-Module
Get-Module
Find-Package
Get-Package
I am calling the below script in my post build configurations:
%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe -NoProfile
-ExecutionPolicy RemoteSigned -file "\Sclddev8\tfs\Scripts\slack-notice.ps1" -Verb RunAs;
However, I keep getting this error:
Send-SlackMessage : The term 'Send-SlackMessage' is not recognized as the name
But I have installed this module in my environment and if I open a PowerShell console or run the file outside of this build process, works without issue.
When you install a Powershell module, you are technically importing the module from your profile every time you open a new Powershell window. By running Powershell with the "-NoProfile" switch, you're preventing the module from being imported (even though it's "installed" and the files are present).
What may be your best option, if you want to keep the "-NoProfile" switch active, is to have a line at the top of your script to import the module before continuing. If you're using Warren Frame's "PSSlack" module, the command you need is:
> Import-Module PSSlack
I hit the same issue.
What helped was... copying the folder into C:\Windows\SysWOW64\WindowsPowerShell\v1.0\Modules.
Yup, it makes a difference.
I'm using Hudson version 1.324 for CI and have a couple of issues:
Environment:
Windows Server 2008
Powershell v1.0
Hudson 1.324 running as a service
Hudson Powershell Plugin installed
Psake (aka. "Powershell Make/Rake" available from Github) 0.23
(All current/latest versions as of this initial post)
I have a Powershell (PS) script that works to compile, run NUnit tests, and if successful, create a 7z file of the output. The PS script works from the command line, on both my local development box as well as the CI server where Hudson is installed.
1) Execution Policy with Powershell.
I initially ran a PS console on the server, ran Set-ExecutionPolicy Unrestricted, which allows any script to be run. (Yes, I realize the security concerns here, I'm trying to get something to work and Unrestricted should remove the security issues so I can focus on other problems.)
[This worked, and allowed me to fire off the PS build script from Hudson yesterday. I then encountered another problem, but we'll discuss that more in item #2.]
Once Hudson could fire off a PS script, it complained with the following error:
"C:\Windows\system32\WindowsPowerShell\v1.0\powershell "&
'OzSystems.Tools\psake\psake.ps1' '.\oz-build.ps1'" The term
'OzSystems.Tools\psake\psake.ps1' is not recognized as a cmdlet, funct
ion, operable program, or script file. Verify the term and try again.
At line:1 char:2
+ & <<<< 'OzSystems.Tools\psake\psake.ps1' '.\oz-build.ps1'"
Using the same command line, I am able to successfully execute the PS script from the command line manually. However Hudson is unable to get PS to do the same. After looking at additional PS documentation I also tried this:
"& 'OzSystems.Tools\psake\psake.ps1' '.\oz-build.ps1'"
and got a similar error. There does not appear to be any documentation for the Powershell plugin for Hudson. I've gone through all the Powershell plugin files and don't see anything that's configurable. I can't find a log file for Hudson to get additional information.
Can anyone help me past this?
2) I spent yesterday wrestling with #1. I came in this AM and tried to dig in again, after restarting the Hudson server/service, and now it appears that the ExecutionPolicy has been reset to Restricted. I did what worked yesterday, opened a PS console and Set-ExecutionPolicy to Unrestricted. It shows Unrestricted in the PS console, but Hudson says that it doesn't have rights to execution PS scripts. I reopened a new PS console and confirmed that the ExecutionPolicy is still Unrestriced -- it is. But Hudson evidently is not aware of this change. Restarting Hudson service again does not change Hudson's view of the policy.
Does anyone know what's going on here?
Thanks, Derek
I just ran into the problem of running powershell scripts in hudson. The thing is that you are running a 32-bit process of Java, and you've configured Hudson for 64-bit but not for 32-bit. See the following thread we created at microsoft.
http://social.technet.microsoft.com/Forums/en/winserverpowershell/thread/a9c08f7e-c557-46eb-b8a6-a19ba457e26d
If your lazy.
1. Start powershell (x86) from the start menu as administrator
2. Set the execution policy to remotesigned
Run this once and your homefree.
When Running PowerShell from a scheduled task or Hudson you want to:
Specify the -ExecutionPolicy parameter (in your case: -Ex Unrestricted)
Specify that command using either -Command { ... } or -File NOT BOTH and not without specifying which you mean.
Try this (except that I don't recommend using relative paths):
PowerShell.exe -Ex Unrestricted -Command "C:\Path\To\OzSystems.Tools\psake\psake.ps1" ".\oz-build.ps1"
To be clear, this will work too:
PowerShell.exe -Ex Unrestricted -Command "&{&'OzSystems.Tools\psake\psake.ps1' '.\oz-build.ps1'}"
The first string after -Command is interpreted as THE NAME OF A COMMAND, and every parameter after that is just passed to that command as a parameter. The string is NOT a script, it's the name of a command (in this case, a script file)... you cannot put "&'OzSystems.Tools\psake\psake.ps1'" but you can put "OzSystems.Tools\psake\psake.ps1" even if it has spaces.
To quote from the help (run PowerShell -?) emphasis mine:
-Command
Executes the specified commands (and any parameters) as though they were
typed at the Windows PowerShell command prompt, and then exits, unless
NoExit is specified. The value of Command can be "-", a string. or a
script block.
If the value of Command is "-", the command text is read from standard
input.
If the value of Command is a script block, the script block must be enclosed
in braces ({}). You can specify a script block only when running PowerShell.exe
in Windows PowerShell. The results of the script block are returned
to the parent shell as deserialized XML objects, not live objects.
If the value of Command is a string, Command must be the last parameter
in the command , because any characters typed after the command are
interpreted as the command arguments.
I have been having the same problems as you (as you've seen from my comments). I have given up on the powershell launcher and moved to running things using the batch file launcher. Even though I had set the system to unrestricted that setting didn't seem to matter to hudson's launcher. I don't know if it runs in some other context or something, even adding things to the global profile.ps1 didn't seem to help. What I ended up doing was running
powershell " set-executionpolicy Unrestricted; & 'somefile.ps1'"
which does what I need, although it isn't ideal. I've e-mailed the plugin author about this and will update.
For question #1, try this (assuming you are using PowerShell 2.0):
"C:\Windows\system32\WindowsPowerShell\v1.0\powershell -executionPolicy Unrestricted -file OzSystems.Tools\psake\psake.ps1 C:\{path}\oz-build.ps1"
You are using "." for the path to oz-build.ps1. I suspect you will need to provide the full path to your oz-build.ps1 file to make this work. Unless the infrastructure that executes the command above happens to have the current dir set correctly. And even if it is set correctly for the "process", that only matters to .NET/Win32 API calls and not to PowerShell cmdlets. Current dir in PowerShell is tracked differently than the process's current dir because PowerShell can have multiple runspaces running simultaneously. That sort of global, mutable value doesn't work in this concurrent scenario.
As for question #2, what account does the Hudson service run under? Make sure that account has executed Set-ExecutionPolicy RemoteSigned (or unrestricted).
I just got through this exact problem. What a pain!
If you are running a 32-bit JVM on a 64-bit Windows, make sure that you set the execution policy for the 32-bit Powershell interface. I found my 32 bit executable here:
C:\Windows\syswow64\Windowspowershell\v1.0\powerhsell.exe
The 32- and 64-bit Powershell environments are completely distinct so setting the execution policy in one has no effect on the other.