use Powershell scripts on a Non-sql server

Question

use Powershell scripts on a Non-sql server

fafful

SSC Eights!

Points: 810
More actions
August 21, 2018 at 7:04 am

#367547

I inherited Powershell scripts that run on a non SQLServer box A and invokes invoke .net commands to connect to SQLserver databases on another box and return datasets. I have the task to install a new server Box B to replace Server Box A that runs windows server 2012. (but No SQLServer install). Can I copy just the Powershell scripts over to the server Box B from server Box A and the scripts will just run or I must install some other dotnet or SQL stuff to have the scripts work same way as they do in Server BoxA. The SQLServer box where the SQL database is hosted has not changed at all.

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply

Sue_H SSC Guru Points: 90860 More actions · Answer 1

fafful - Tuesday, August 21, 2018 7:04 AM
I inherited Powershell scripts that run on a non SQLServer box A and invokes invoke .net commands to connect to SQLserver databases on another box and return datasets. I have the task to install a new server Box B to replace Server Box A that runs windows server 2012. (but No SQLServer install). Can I copy just the Powershell scripts over to the server Box B from server Box A and the scripts will just run or I must install some other dotnet or SQL stuff to have the scripts work same way as they do in Server BoxA. The SQLServer box where the SQL database is hosted has not changed at all.

Maybe or maybe not. It really depends on what Powershell version is being used, what modules are being called, any other assemblies required, etc. So those are all things you would need to figure out from the scripts. A few things I can think of off the top of my head that you can run in Powershell to check things between the two servers:
##shows modules loaded Get-Module

##shows modules available Get-Module -ListAvailable

##get Powershell, CLR versions $psversiontable

##should just always check this. get-executionpolicy

##version of SMO [System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SqlServer.Smo")

Sue

SQLPirate SSCrazy Points: 2880 More actions · Answer 2

Just to tack onto Sue's advice, you should also look at the account that's running the scripts.
Running Get-Module -ListAvailable from Powershell running under the context of the account that will be running the scripts might give you different results than what you might see if you just launched Powershell as yourself.

Sue_H SSC Guru Points: 90860 More actions · Answer 3

SQLPirate - Tuesday, August 21, 2018 3:59 PM
Just to tack onto Sue's advice, you should also look at the account that's running the scripts.
Running Get-Module -ListAvailable from Powershell running under the context of the account that will be running the scripts might give you different results than what you might see if you just launched Powershell as yourself.

Thanks for adding that - it's a great point. And now you got me thinking of more based on the account running scripts - profile, module path. Those can be checked with
##Paths searched for Posh Modules $env:PSModulePath

##Check if profile exists Test-Path $profile

I'm guessing there are still more.....

Sue

Steve Jones - SSC Editor SSC Guru Points: 734552 More actions · Answer 4

If you need the SQLServer module: https://docs.microsoft.com/en-us/sql/powershell/download-sql-server-ps-module?view=sql-server-2017