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
Related
I have a machine i would like to install a module on, specifically SwisPowerShell for working with SolarWinds. Internet is disabled on it so i cant use install-module, so i manually downloaded the .nupkg from another machine and went through the steps of unpacking the files into the correct folders. https://learn.microsoft.com/en-us/powershell/scripting/gallery/how-to/working-with-packages/manual-download?view=powershell-7.2. all the .dll files and the windows powershell datafile i have tried in both directories "C:\Program Files\WindowsPowerShell\Modules\SwisPowerShell\3.1.0.343" and "C:\Users\username\Documents\WindowsPowerShell\Modules\SwisPowerShell\3.1.0.343". Importing the module with "import-module -name SwisPowerShell -Global -force -Verbose" shows that everything loads correctly, but then running "get-module SwisPowerShell -Verbose" returns nothing. even loading each dll individually with "add-type -path "C:...\somefile.dll" shows nothing. running "get-module -ListAvailable" shows the module in both (or either) directories as they should be. using "get-help cmdletname" and "get-command cmdletname" shows the correct cmdlet definitions. trying to run any of the cmdlets returns "The term 'connect-swis' is not recognized as the name of a cmdlet, function... yada yadda" for all of the cmdlets. its like powershell sees the files but refuses to use them. Am i missing a step that tells powershell that this is a valid module to use? could it be blocked somehow? what extra steps does install-module do that a manual install does not that i could try?
Try running process monitor while installing on another machine. You might find out it's doing some registry changes too.
I have a Powershell script to install TCP/IP printers on Windows 10 that uses PNPUTIL to load drivers. When the script is run from a Powershell window, everything works great.
When I launch the script from a shortcut using the format
C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe -file MyScript.PS1
I get an error 'The term 'pnputil.exe' is not recognized as the name of a cmdlet, function, script file, or operable program' when PNPUTIL is called. The rest of the script runs fine.
Relevant code:
Write-Host `n 'Installing printer driver..'
pnputil.exe /add-driver "\\myServer\HP UPD PCL 5\hpcu180t.inf"
Any ideas as to why this won't work when launched from a shortcut?
EDIT:I tried using
& pnputil.exe /add-driver "\\myServer\HP UPD PCL 5\hpcu180t.inf"
as referenced in
Running CMD command in PowerShell
but I still get the error. I also tried
start-process pnputil.exe /add-driver "\\myServer\HP UPD PCL 5\hpcu180t.inf"
but got a similar error that pnputil.exe could not be found.
Both of these options work from a Powershell prompt, but again, fail when launched from a shortcut.
Thank you in advance.
You're invoking a 32-bit instance of PowerShell on a 64-bit system, and that instance doesn't see pnputil.exe (by filename only).
Instead of:
C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe -file MyScript.PS1
use:
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -file MyScript.PS1
Folder C:\Windows\SysWOW64 is where the 32-bit executables live.
Paradoxically, for historical reasons, it is C:\Windows\System32 that houses the 64-bit executables.
If, for some reason, you do need to run a 32-bit instance of PowerShell, you can invoke pnputil.exe by its full path:
It only exists as a 64-bit executable in the 64-bit system folder, which 32-bit processes can access as C:\Windows\SysNative:
C:\Windows\SysNative\pnputil.exe
I'm developing a quite large automatic build in TFS2017 with a local VSTS build machine. My custom tasks will be mostly in PowerShell.
The inline PowerShell task handles only 500 or so characters and is too small to use for most tasks. Right now I'm editing my Powershell script, check it in, test run, read log for errors, correct, check in again and so on.
This is a bit tedious and I wonder if there are any options. I would like to avoid checking in each change in the script. Are there any options like executing my Powershell tasks from a network location during development of the build process?
You can specify UNC file path in PowerShell task.
You also can store the script files in a server (e.g. FTP), then download the file to working directory during build through PowerShell or others task.
On the other hand, there is PowerShell on Target machines task that can execute PowerShell scripts on remote machines.
You can use dot sourcing with your UNC path:
PS> . \\server\path\to\your\scriptmcscript.ps1
or use the invocation operator:
& \\server\path\to\your\scriptmcscript.ps1
You can use UNC path for the file with Powershell Task.
Or you could use the Powershell on target machine to run it.
But be careful about your choice. You have to keep in mind that who is running your script is the build/deployment agent. So while you are running it in your corporate network everything will be fine, because your agent can see your UNC path.
The moment you use that agent on a machine outside your network you will have to think about another solution, which may include saving your powershell file to a repo like Git or TFVC and then download the file to the local computer where you are running the agent.
This is the only way that works for me, call PowerShell from a .batch script with execution policy set to bypass (scope - process only)
-NonInteractive = do not prompt for confirm
-NoProfile = run under system context
powershell.exe -NoProfile -ExecutionPolicy Bypass -NonInteractive -Command C:\Users\User\Script.ps1
This simple copy line in powershell runs interactively but when I try to schedule in Windows task scheduler, it shows that it completed but it did no work. I.e., it did not copy the file. I tried using the steps listed in "Run PowerShell Scripts from Task Scheduler" but still no luck. If anyone can give me some advice, I would be greatful. Below is the one line script (using UNC paths gets multiple access prohibited errors) If I could get the share names working first, that would be a start.
V:\ is a path mapped to a Windows 7 drive and D:\ is on the Windows 2012 server. The task history gives task start and stop times but no detailed info.
Copy-Item -Path V:\data\bar\foo\Outlook\*.pst -Destination D:\Data\foobar\Outlook
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.