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
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.
When I try to execute Powershell command, it gives the error:
Connect-SPOService : The term 'Connect-SPOService' 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.
Tried uninstalling and reiinstalling S P Online Management shell. None of the SPO commands are working.
On my system this came down to a conflicting .dll (different versions) that was found in both the SharePoint PowerShell module folder and the Global Assembly Cache.
I deleted the following file from the GAC:
C:\Program Files\WindowsPowerShell\tmp\Microsoft.SharePoint.Client.Publishing\v4.0_16.0.0.0__71e9bce111e9429c\Microsoft.SharePoint.Client.Publishing.dll
After that everything was running smoothly. Full details on research leading to this is found here:
https://www.easy365manager.com/the-term-connect-sposervice-is-not-recognized/
Are you using the cmdlet in the SharePoint Online Management Shell or in the PowerShell? If you are using it in PowerShell, still you need to import the module with
Install-Module -Name Microsoft.Online.SharePoint.PowerShell
Besides, ensure you are running the management shell under administrator privilege.
Here is a doc which may be helpful:https://learn.microsoft.com/en-us/powershell/sharepoint/sharepoint-online/connect-sharepoint-online?view=sharepoint-ps
On mac run the following command:
rm -rf Users/<username>/.local/share/powershell/Modules/Microsoft.Online.SharePoint.PowerShell/16.0.22810.12000/Microsoft.SharePoint.Client.Publishing.dll
PS: replace with username
Not sure if this is for stakoverflow or serverfault.
I am deploying a Powershell script using MS Intune. The script works when run locally, but when deployed I get the error below:
Remove-LocalGroupMember : The term 'Remove-LocalGroupMember' 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. At
C:\Program Files (x86)\Microsoft Intune Management
I am not sure why this commandlet is unavailable as it is definitely there if I open a powershell and run this command.
I am logging the $user variable to check that it is not null or running under a different context.
The code is quite simple as below:
$user = $(whoami)
$user | Out-File 'C:\powershelllog.log'
Remove-LocalGroupMember -Group Administrators -Member $user
I believe I've run into the same issue as you are having. I've been trying to create a local admin account on machines. Running the powershell script with the system context in Intune. What I've found is that you must check: "Run script in 64 bit PowerShell Host" inside of the Intune where you import powershell scripts.
Apparently not all commands are available with the 32 bit ps console running that way.
I also used the get-command to determine what module the command that was reporting not found was is in, and used the import-module at the top of my script in case.
Working on a corporate laptop with no access to local admin but with the execution policy set to unrestricted, when trying to import the SQLPS cmdlets I receive an error indicating a problem with the path, shown below.
Why is the import-module command looking at my AppData\Local\Temp folder?
If a reinstall of SSMS does not do the trick, try installing the PowerShellTools.msi package of the SQL Server feature pack that corresponds with the latest server you will be working on.
SQL Server 2014
SQL Server 2016
I would also recommend running Get-Module Sqlps | Format-Table -Property ModuleType,Name,Path to check if there are multiple copies of the module and remove them as needed.
I'm coming onto a project that uses PowerShell to script the build. The build makes use of the WebAdministration module to manage the local IIS instance. When I run the build script the following error is thrown when trying to import WebAdministration.
Error: 06/29/2016 17:28:35: At
C:\dev\src\nib-ravendb\build\ConfigureIis.ps1:10 char:1 +
Import-Module WebAdministration + ~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~
[<<==>>] Exception: The specified module 'WebAdministration' was not
loaded because no valid module file was fo und in any module
directory. ERROR: 1
How ever when I run Import-Module WebAdministration at the PowerShell command line the module is imported and I can use features from it. Subsequently running the build script still fails.
I have IIS 7.5 and PowerShell 4
Does anyone have an idea why this import would be failing in the script but not at the command line, and how to fix it?
For servers you need to install the role Management Tools under Web Server (IIS) to use the WebAdministration module. To see if you have the module available use Get-Module -ListAvailable.
For Windows 7 to 10 you will need to install the feature IIS Management Scripts and tools under Internet Information Services >> Web Management Tools.
You could try manually locating the WebAdministration .psd1 file and then import it. Use $env:psmodulepath to help locate where your modules are stored then run:
Import-Module -Name 'C:\Windows\System32\WindowsPowerShell\v1.0\Modules\WebAdministration\WebAdministration.psd1'
If Server 2008 you could try the following but this may not work on 2012 and upwards:
Add-PSSnapin WebAdministration
Note You will need to run the script with administrator rights to be able to load the WebAdministration module with Import-Module or Add-PSSnapin.
Also check that you have PowerShell's execution Policy set to Unrestricted:
Set-ExecutionPolicy unrestricted
You might want to see this Question.
I had the same situation, i've fixed it installing the Windows Feature Web-Scripting-Tools on W2016 Server:
Add-WindowsFeature Web-Scripting-Tools
In the end there was a problem something, possibly chocolatey?, was truncating $env:PSModulePath to the first entry, this is why the script was working if I typed it in but not in the script.
I found it by logging $env:PSModulePath at different points in the scripts that I was running.
I worked around it by reordering the entries in $env:PSModulePath.
Have a look at #Richard's answer for some other good suggestions.
In my case (Windows 10) I was using Powershell 7 and this simply refused to install the WebAdministration module, despite it being present in Windows Features.
Using a previous version of PS: e.g. Developer PowerShell for VS worked.