I am trying to install software on some windows machines using ansible. I have tried raw and win_package to do this. Both of them result in a 1603 error from windows. The same command run fine when logged into the machine using RDP using the same user account.
`
- name: install RDE
raw: “c:\Temp\RDEInstall.exe /passive SILENT_INSTALL=true’”
register: raw_output
- debug: var=raw_output.stdout
- debug: var=raw_output.stderr
`
This produces the following output:
`
TASK [RDE : install RDE] *******************************************************
ok: [installtest]
TASK [RDE : debug] *************************************************************
ok: [installtest] => {
“raw_output.stdout”: “”
}
TASK [RDE : debug] *************************************************************
ok: [installtest] => {
“raw_output.stderr”: “”
}
`
The Windows application log shows a return code of 1603 for event 1033 for this install. As stated before, if the raw command is executed on the machine (e.g. powershell window) via RDP, it installs fine. This leads me to believe the installer is missing access to something when it’s executed via ansible that it has when executed on the machine.
Any help would be appreciated.
Thanks!
1603 is unfortunately not a lot of help. It seems to mean ‘something went wrong’ but doesn’t detail why.
Most msi type installers can write a log of what is going on I suggest you try running it with whatever command line options are available to get it to generate a log and look through that (probably from the bottom up - there’s often a lot of noise in msi logs).
Annoyingly a lot of installers still expect a GUI unless you explicitly tell them not to use the GUI.
ansible uses winrm and you dont get full permission in the remote session.
try “invoke-command” with explicit credentials
eg
$Username = 'admin'
$Password = 'password'
$pass = ConvertTo-SecureString -AsPlainText $Password -Force
$Cred = New-Object System.Management.Automation.PSCredential -ArgumentList $Username,$pass
Invoke-command –computername . -credential $cred –scriptblock {rdsinstall.exe}
I looked at the log generated by the installer; however, it doesn’t help me at all. Maybe it will provide some incite for you? Here are the entries from the failure:
`
MSI (s) (DC:58) [14:37:35:944]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI1FB5.tmp, Entrypoint: InstallExecuteSeq
Action start 14:37:35: InstallExecuteSeq.
SFXCA: Extracting custom action to temporary directory: C:\Windows\Installer\MSI1FB5.tmp-
SFXCA: Binding to CLR version v4.0.30319
Calling custom action CustomActions!CompanyNameWix.CustomActions.InstallExecuteSeq
CustomAction InstallExecuteSeq returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Action ended 14:37:36: InstallExecuteSeq. Return value 3.
Action ended 14:37:36: INSTALL. Return value 3.
… *** a bunch of properties listed *** …
MSI (s) (DC:FC) [14:37:36:911]: Note: 1: 1708
MSI (s) (DC:FC) [14:37:36:911]: Note: 1: 2205 2: 3: Error
MSI (s) (DC:FC) [14:37:36:911]: Note: 1: 2228 2: 3: Error 4: SELECT Message FROM Error WHERE Error = 1708
MSI (s) (DC:FC) [14:37:36:911]: Note: 1: 2205 2: 3: Error
MSI (s) (DC:FC) [14:37:36:911]: Note: 1: 2228 2: 3: Error 4: SELECT Message FROM Error WHERE Error = 1709
MSI (s) (DC:FC) [14:37:36:911]: Product: – Installation failed.
MSI (s) (DC:FC) [14:37:36:935]: Windows Installer installed the product. Product Name: . Product Version: 1.10.97. Product Language: 1033. Manufacturer: . Installation success or error status: 1603.
MSI (s) (DC:FC) [14:37:36:937]: Deferring clean up of packages/files, if any exist
MSI (s) (DC:FC) [14:37:36:937]: MainEngineThread is returning 1603
MSI (s) (DC:B0) [14:37:36:939]: RESTART MANAGER: Session closed.
MSI (s) (DC:B0) [14:37:36:939]: No System Restore sequence number for this installation.
=== Logging stopped: 6/8/2016 14:37:36 ===
MSI (s) (DC:B0) [14:37:36:940]: User policy value ‘DisableRollback’ is 0
MSI (s) (DC:B0) [14:37:36:940]: Machine policy value ‘DisableRollback’ is 0
MSI (s) (DC:B0) [14:37:36:940]: Incrementing counter to disable shutdown. Counter after increment: 0
MSI (s) (DC:B0) [14:37:36:940]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts 3: 2
MSI (s) (DC:B0) [14:37:36:940]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts 3: 2
MSI (s) (DC:B0) [14:37:36:941]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1
MSI (s) (DC:B0) [14:37:36:941]: Restoring environment variables
MSI (s) (DC:B0) [14:37:36:941]: Destroying RemoteAPI object.
MSI (s) (DC:4C) [14:37:36:941]: Custom Action Manager thread ending.
MSI (c) (14:EC) [14:37:36:942]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1
MSI (c) (14:EC) [14:37:36:942]: MainEngineThread is returning 1603
=== Verbose logging stopped: 6/8/2016 14:37:36 ===
`
I seem to recall when I set up the JBoss Operations Network agent to do the install, I had to check “Allow service to interact with the desktop” in the service properties of the agent to get it to work. This is because the installer still pops up windows even though it’s set to be an unattended install. Is there a general cli option to explicitly tell any installer not to use the GUI? Or is this something that has to be coded into the installer explicitly?
it fails on a custom action, you need to open the msi to see what it does. For example, if customaction is a script requireing access to $host or other interactive environment it’s gonna fail since you don’t have that. Not much we can do about that I’m afraid 