1

I intend to install remotely a sql-instance. I have a share with sql-binaries and a config-file. My script is:

import-module sqlserver -DisableNameChecking
$setupDrive = "\\sqlshare\sql_source\ISO\Setup\SW_DVD9_NTRL_SQL_Svr_Ent_Core_2019Dec2019_64Bit_English_OEM_VL_X22-22120"
$fileExe =  "$setupDrive", "setup.exe" -join("\")
$configurationFile = "\\sqlshare\sql_source\ISO\ConfigurationFileMSSQLSERVER.ini"
$session = New-PSSession -ComputerName "xxxx_yyyy"
Invoke-Command -ScriptBlock{& $args[0] /CONFIGURATIONFILE=$args[1]} -Session $session 
-ArgumentList $fileExe, $configurationFile

I'm still getting an error and don't know how to interpret it:

An error occurred while creating the pipeline.
+ CategoryInfo          : NotSpecified: (:) [], RuntimeException
+ FullyQualifiedErrorId : RuntimeException
+ PSComputerName        : xxxx_yyyy

I have a PS-script on the server A:(C:\temp\script.ps1) with this content:

import-module sqlserver -DisableNameChecking
& ("\\server1-ssp1102.my.domain\sql_source\Setup\setup.exe 
/CONFIGURATIONFILE=\\server1-ssp1102.my.domain\sql_source\SQLUnattended\ConfigurationFileMSSQLSERVER.ini")

I want to execute this script on the server B (installs a sql server). This doesn't work:

invoke-command -computer ServerB -FilePath C:\C:\temp\script.ps1 -credentials (get-credential)

Update once again: The complete call looks like following:

# A sample target computer.
$computer = 'myComputer'
# Obtain the credentials for the remote session and store them in a 
variable.
$cred = Get-Credential my\user

Invoke-Command -ComputerName $computer -Credential $cred {
$setup = '\\myShare-xxxx.my.domain\sql_source\Setup\setup.exe'
$config = '\\myShare-yyy- xxx.my.domain\sql_source\SQLUnattendedInstallation\ConfigurationFileMSSQLSERVER.ini'
$cu = '\\my-domain-xxxx.my.domain\sql_source\SQLUnattendedInstallation2019\CU'
$null = New-PSDrive -Credential $using:cred -Name cu -Root $cu -PSProvider FileSystem
$null = New-PSDrive -Credential $using:cred -Name setup -Root (Split-Path -Parent $setup) -PSProvider FileSystem
$null = New-PSDrive -Credential $using:cred -Name config -Root (Split-Path -Parent $config) -PSProvider FileSystem
& $using:setup /CONFIGURATIONFILE=$using:config
}

Update:2 I've created a file (test5.ps1) with this content:

import-module sqlserver -DisableNameChecking
$setup = '\\xxx-xxx-xxx.xxx.xxx\sql_source\Setup\setup.exe'
$config = '\\xxx-xxx- xxx.xxx.xxx\sql_source\SQLUnattendedInstallation2019\ConfigurationFileMSSQLSERVER.ini'
$cu = '\\xxx-xxx-xxx.xxx.xxx\sql_source\SQLUnattendedInstallation2019\CU\SQLServer2019-KB5014353-x64.exe'
$null = New-PSDrive -Credential $using:cred -Name cu -Root (Split- 
Path $cu) -PSProvider FileSystem
$null = New-PSDrive -Credential $using:cred -Name setup -Root 
(Split-Path -Parent $setup) -PSProvider FileSystem
$null = New-PSDrive -Credential $using:cred -Name config -Root 
(Split-Path -Parent $config) -PSProvider FileSystem

& $setup /CONFIGURATIONFILE=$config

and then I'm calling this script like this:

Invoke-Command -ComputerName xxx-sql-yyy -FilePath 
C:\Users\xxx\Documents\test\test5.ps1 -Credential (Get-Credential 
my\user)

then the script begins to install the sql server on the remote machine, but still I get an error (in the summary.txt from the sql server installation on the remote machine): Access is denied. Error result: -2061762559 Result facility code: 1308 Result error code: 1

meaning: still a problem with the credentials.

Update 3:

  1. The script (test5.ps1) stays untouched
  2. on the caller-site: $cred = get-credential Invoke-Command -ComputerName xxx-sql-yyy -FilePath C:\Users\xxx\Documents\test\test5.ps1 -Credential $cred

Unfortunately the same error: Access denied etc.

Purclot
  • 483
  • 7
  • 22
  • 1
    Are you able to run _any_ command on the remote machine? Say, a simple `hostname` call? If so, are you able to connect from the remote server to the `$setupDrive` share from within your remote session? You may be hitting the [double-hop problem](https://learn.microsoft.com/en-us/powershell/scripting/learn/remoting/ps-remoting-second-hop?view=powershell-7.2) – boxdog Aug 18 '22 at 13:34
  • hi, I can run any command on the remote machine. I'm concern about the "-ArgumentList" and the parameter I'm using that way. Is this the correct syntax for $args[0] and $args[1]? – Purclot Aug 18 '22 at 14:00
  • 1
    Check out the [using](https://learn.microsoft.com/en-gb/powershell/module/microsoft.powershell.core/about/about_remote_variables?view=powershell-7.2#using-local-variables) prefix, which is a better way to pass variables. – boxdog Aug 18 '22 at 14:08
  • using doesn't help. what else can I do ? – Purclot Aug 26 '22 at 12:15
  • 1
    Your syntax is correct. Have you looked into the double-hop problem pointed out by @boxdog? [This answer](https://stackoverflow.com/a/48692809/45375) shows a workaround. If that works, we can close this post as a duplicate. – mklement0 Aug 29 '22 at 12:29
  • @mklement0: thanks for your answer. To round the things up: I have a PS-Script on the server "A", which (started locally) installs a SQL Server and works perfectly. The script uses e.g. sql-binaries and config.ini file lying on a share. I must start the script from the server "B". The server "B" can reach the server "A", the share etc. 1. How can I check for sure if I have a "double-hop" problem, getting only the a simple error: "access denied" or "error in the pipe"? 2. why do I have to provide the credentials being (I'm logged on with the same account on both servers) a sys-admin? – Purclot Aug 29 '22 at 19:08
  • 1
    @Purclot, the linked answer as well as boxdog's link above have background information about the double-hop problem - I'm unsure about the specific symptoms, but in short: irrespective of what credentials you use for remoting, the remotely running script block cannot access resources on yet _another_ machine. The suggested workaround requires you to pass credentials explicitly so you can use them to establish a (temporary) drive mapping to the share of interest on the other machine, after which accessing the share works. – mklement0 Aug 29 '22 at 19:13
  • 1
    @mklement0, Thanks a lot, I'll test it immediately tomorrow (my German time is 22 hours and my shift is over for today). – Purclot Aug 29 '22 at 19:55
  • @mklement0: thanks for your solution, I actualized my question. In your solution you're using: $null = New-PSDrive -Credential $using:cred -Name dummy -Root (Split-Path -Parent $using:script) -PSProvider FileSystem I still don't get it run having two parameters: setup.exe and config-ini, two different shares etc...can you help.. – Purclot Sep 07 '22 at 15:32
  • A quick language tip: you meant _updating_ (_actualizing_ is a Germanism ("aktualisieren")). – mklement0 Sep 07 '22 at 22:03
  • Applying the workaround in the linked answer would require you to incorporate the `New-PSDrive` call in your `C:\C:\temp\script.ps1` file. – mklement0 Sep 07 '22 at 22:06
  • @mklement0: sorry for my German-English(and thanks for correcting me). I updated the script once again, now I'm getting an error: The value of the using variable '$using:setup' cannot be retrieved because it has not been set in the local session. I'm heading nowhere.. – Purclot Sep 09 '22 at 11:22
  • @mklement0: there is an Update2...still no success... – Purclot Sep 09 '22 at 13:07
  • 1
    In the first update you're defining `$setup` in the remote script block itself, so you must refer to it as a local variable, `$setup`. In the second update you're using `$using:cred` inside the script, which means that you must first define a `$cred` variable on the caller's side. – mklement0 Sep 09 '22 at 15:49
  • @mklement0: update 3, no success.... – Purclot Sep 12 '22 at 14:46
  • Unfortunately, I'm out of ideas - the approach works in principle. Are the credentials the right ones for accessing all these shares? That is, if you run the `New-PSDrive` calls _locally_ with `$cred`, do they work? – mklement0 Sep 12 '22 at 15:57
  • @mklement0: I've checked New-PSDrive locally with $cred, it works... – Purclot Sep 12 '22 at 19:39
  • 1
    @mklement0: thanks for your support, I appreciate it very much. – Purclot Sep 13 '22 at 19:37
  • 1
    You're welcome, @Purclot. I'm glad you found a solution. – mklement0 Sep 13 '22 at 19:38

1 Answers1

1

the tricky problem was inside of the configuration.ini file for unattended sql server installation, namely:

;SQLSVCACCOUNT="myDomain\theServiceAccount$" # originally
SQLSVCACCOUNT="NT Service\MSSQLServer" # changed
;AGTSVCACCOUNT="myDomain\theAgentAccount$" # originally
AGTSVCACCOUNT="NT Service\SQLServerAgent" # changed

The error-message "Access denied" was all about those accounts. After the installation I have to change the service accounts for the sql- and agent services and that's all.

Purclot
  • 483
  • 7
  • 22