Invoke-SQLCMD cmdlet does not work when executed through powershell script (.ps1)
Following error is logged:
[error]Windows PowerShell is in NonInteractive mode. Read and Prompt
functionality is not available. [error]Process completed with exit
code 0 and had 1 error(s) written to the error stream.
When executed through interactive window it asks for user confirmation.
Is there a work around to pass the default value Yes when executed through scripts?
Install 'Windows PowerShell Extensions for SQL Server' from the Microsoft® SQL Server® 2008 R2 Feature Pack page (it's about halfway down the page). Make sure you pick the correct flavor for your instance (32 or 64 bit).
Run these two commands before calling invoke-sqlcmd in your script:
Add-PSSnapin SqlServerCmdletSnapin100
Add-PSSnapin SqlServerProviderSnapin100
Related
We have recently started using SQL Server 2012 SP3 and building the SQL server 2012 using a PowerShell script. There is a requirement in our automation process to run multiple database scripts on a db and I have found Invoke-Sqlcmd very reliable until I found this issue.
When I run Invoke-sqlcmd with a proper set of parameters in PowerShell's debug mode on the system on which the SQL server is installed recently, I don't have problem.
PowershellCommand : Invoke-Sqlcmd -InputFile $sStrJBSPExecRolePath -ServerInstance $sStrSQLName -ErrorAction Stop
But when I execute same query through a PowerShell automation script after rebuilding the same server, I end up getting below error
The term 'Invoke-Sqlcmd' 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 again.
I did research online many suggested to Import SQLPS, etc., so for testing I added the below command in my script
get-pssnapin -Registered
Import-Module “sqlps” -DisableNameChecking**
Even after adding the above into the script, I still end up with same error. But when I run the same script manually it runs perfectly fine. I don't understand what is wrong.
PowerShell automation script - This script installs the .Net Framework 3.5, SQL Server 2012, SQL Server 2012 SP3, and then loads the SMO assembly that I use to change SQL settings such as the Max Memory limit of SQL.
Open up PowerShell as an Administrator and install the sqlserver module by Install-Module sqlserver
After the module has installed, the module commands including the Invoke-sqlcmd should be readily available.
You can check the same using Get-Command -Module sqlserver.
If this module is not readily available, you can Import-Module sqlserver after installing it.
This is not a complete solution, but just a work around which is working for me.
When you execute the query from automation the user which is executing that is not having access to the sqlcmd. Execute you command for the directory where your sqlcmd.exe is present.
Just put
CD "C:\Program Files (x86)\Microsoft SQL Server\Client SDK\ODBC\130\Tools\Binn".
to get the location for sqlcmd search the location for SQLCMD.exe in the search box.
if not found, you need to install that where it is missing, but in your case I think it is present, you just need to get the location right.
Also you will need set the path variable for the user executing the automation script or else it will only recognize the sqlcmd, but wont execute that.
$env:Path += ";C:\Program Files (x86)\Microsoft SQL Server\130\DTS\Binn\"
you can get this path from you local user for which it is working by $Env:Path
I'm trying to emulate powershell version 2.0 in version 4.0
The following just freezes the application:
PS H:\> powershell.exe -version 2.0
I do get the following text but and the console continues to run and I am unable to execute further script.
Windows PowerShell
Copyright (C) 2009 Microsoft Corporation. All rights reserved.
As far as I'm aware, the command window in ISE is not a real console window. It's just pretending that it is. In reality, it's running the commands in the background and copying the output to the command window.
Note that when you try to run cmd.exe, you get this:
Cannot start "cmd". 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
Similarly, running powershell.exe alone gives me this:
Cannot start "powershell". 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
I'm not sure why powershell -version 2.0 works. The ISE must think you're calling it non-interactively.
Note that it's not freezing. It's waiting for the process to end. You can end it by pressing Ctrl+C.
Using Start-Process powershell.exe -ArgumentList "-Version 2.0" opens a new console window.
So I'm trying to get a script to run a script from a server remotely on another server. This session has to be 32 bit because of a cmdlet. And the script has to be run as admin.
I've tried this:
Invoke-Command -ComputerName isg108-81 -FilePath C:\inetpub\scrip\ConvertAppvPackages.ps1 -ConfigurationName microsoft.powershell32 -credentials Admin
So this starts the 32 bit version of powershell, but as soon as the script gets to the part where it needs elevated rights the shell tells me:
You must run this cmdlet using a Windows PowerShell elevated command prompt . To run
an elevated command prompt, right-click the Windows PowerShell or Command Prompt Start
menu object that you are using to start your Windows PowerShell sessions, and then
Select Run as administrator.
Anybody got any ideas?
Thnx a lot for your help!
If the server is a 64 bit OS, you'll have to call the 32 bit powershell.exe. What if you Invoked the server to run the 32 exe and run the script? Since your invoking it the program won't show up and the script would have to output some file to see any results.
So it turned out that the ConverFrom-AppvLeagcyPackage cmdlet somehow is broken and can't be executed remotely. As a solution I used the program Psexec to run the script remotely, although it only works if you run it as the system user.
Thank you non the less for your help!
I'm getting the following error when running PowerShell scripts on a remote server:
Starting the CLR Failed with HRESULT 8007000e
This is basically how I'm running/calling the scripts:
On the local server I'm running a CMD script that calls a PowerShell script to create a remote session to a remote server. In the PowerShell script I also call a CMD script to run on the remote server like so:
$Script = [scriptblock]::create("cd $BuildPath | cmd.exe /c install.cmd $apptype")
The install.cmd script runs on the remote server and calls a PowerShell script that executes a series of tasks.
powershell ./Install.ps1 -BuildNum %BUILDNUM%
After the tasks are complete, the PowerShell script then calls another PowerShell script to run a separate series of tasks. This is when I hit the above error, when the second PowerShell script is called.
This is how the second PS1 script is called from the first PowerShell script:
powershell "& {. $BinToolsSrc\PostInstallValidation.ps1 -BuildNum $BuildNum -Test 'True'; Run-Validation -App $App -AppLoc $AppLoc -Env $Env:ENV -Site $Site -AppPool $AppPool -Config $Config -EnvConfig $EnvConfig -DllPath $DllPath}"
What usually causes the type of CLR error that I'm getting and how do I resolve it?
NOTE: I do not get this error when I run the install script locally on the remote server.
Thanks in advance!
UPDATE: Installing PowerShell 3 on the remote server seems to have solved the problem as it targets the .NET 4.0 runtime.
I too had the same problem because I have changed some path settings in my VScode unknowingly.
I have changed the settings to command prompt which works fine for me now...(This might not be the best solution though).screenshot
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.