3

I'm trying to install a msi file on a remote server using powershell.

Server 1 is my build server and server 2 is my application server. When the build server finishes a buil, I want to trigger a powershell script to install the latest version to my application server.

I'm using the following command to create a session and execute the installation:

# Create session to Application Server
$Session = New-PSSession -Name <ApplicationServer> -ComputerName <ApplicationServer> -Auth CredSSP -cred OURDOMAIN\MyUser 

# Prepare expression and create script block
$Script = "Invoke-Expression 'msiexec /i <InstallerFile> /qn /L*v C:\Temp\install_fail.log'"
$ScriptBlock = [Scriptblock]::Create($Script)

# Execute in the session
Invoke-Command -ScriptBlock $ScriptBlock -Session $Session

# Clean up the session
Remove-PSSession $Session

The log has the following error (see attachment install_fail.log for full log)

MSI (s) (C4:1C) [17:08:05:333]: Note: 1: 1708 
MSI (s) (C4:1C) [17:08:05:333]: Product: WindowsService1 -- Installation failed.

MSI (s) (C4:1C) [17:08:05:335]: Windows Installer installed the product. Product Name: WindowsService1. Product Version: 8.0.0.0. Product Language: 1033. Manufacturer: MyCompany. Installation success or error status: 1603.

When I start a session on the powershell command promt and execute the installation the installation succeeds (see attachment install_success.log for full log): ENTER-PSSession -ComputerName Invoke-Expression 'msiexec /i /qn /L*v C:\Temp\install_success.log' exit

When I print whoami in both cases it returns OURDOMAIN\MyUser.

Microsoft lists the following regarding the 1603: (http://support.microsoft.com/kb/834484) The folder that you are trying to install the Windows Installer package to is encrypted.

The folder is not encrypted

The drive that contains the folder that you are trying to install the Windows Installer package to is accessed as a substitute drive.

The drive is a partition on the harddisk of the server

The SYSTEM account does not have Full Control permissions on the folder that you are trying to install the Windows Installer package to. You notice the error message because the Windows Installer service uses the SYSTEM account to install software.

The SYSTEM account has Full Control on the drive and all folders.

Please advise...

Bassie
  • 25
  • 1
  • 6
  • You usually use -Auth CredSSP when running into a second hop problem. Is the install file back on the build server? If so, as an experiment, copy the install file to the application server so the file is local and try again without -Auth CredSSP. – Keith Hill Jan 28 '14 at 15:30
  • Thank you for your answer, but I'm sorry to say that it did not solve the 1603 issue. – Bassie Jan 29 '14 at 11:11
  • And if you log directly (or via RDP) into the server with your credentials and run the msi command line to install - does that work? Just trying to figure out if the issue is PS remoting related. – Keith Hill Jan 29 '14 at 18:17
  • When I login using `ENTER-PSSession -ComputerName Invoke-Expression 'msiexec /i /qn /L*v C:\Temp\install_success.log' exit` it installs without a problem – Bassie Jan 30 '14 at 09:02
  • Where is the MSI file located in both instantiations? Is the MSI file local in both cases? On a file share? Also, why use Invoke-Expression? You can run msiexec directly from PowerShell. – Keith Hill Jan 30 '14 at 14:56
  • At first I had the msi file on a file share, but since that did not worked I ruled out network (access) issues by copying the msi to the destination server. I stopped my pursuit for a solution and went with a different approach, normally I would not give up, but I'm on a tight schedule. Thanks for your time and thoughts. – Bassie Feb 03 '14 at 08:32

2 Answers2

0

Have you tried using PSEXEC? or are you using powershell for a reason? I find that easier for remote installs than trying to go through powershell.

Just PSEXEC into the server CMD. Copy the files locally then run MSIExec to install.

Dane Boulton
  • 1,305
  • 1
  • 11
  • 15
  • I switched to a different approach. Thanks for your time and thoughts. – Bassie Feb 03 '14 at 08:43
  • @Seppie: Would you mind explaining your "different approach" so other people (like me) can also solve this problem? You can actually write an answer to your own question and even mark it as the solution to the problem. – AudioDroid Jan 18 '18 at 20:12
  • @AudioDroid, see my answer below. – Bassie Jan 19 '18 at 07:54
-1

I ended up writing a second PowerShell script that runs on the server watching a specific folder for new msi files. The script runs the first script that actually performs the installation tasks.

ndemou
  • 4,691
  • 2
  • 30
  • 33
Bassie
  • 25
  • 1
  • 6
  • To anyone considering this method be careful of who has write access to the special folder with the msi's. Whoever has that access has full control over the server. – ndemou Oct 12 '20 at 19:42