Caliber silent installation is failing only when deployed by SCCM - sccm

I have an installation for Caliber Author Suite (Micro Focus is the publisher) and my installation works when I run as system admin on the client using command prompt. I navigate to the ccmcache and run the exe with the following command line arguments:
caliber-authorsuite-115-hf7.exe /V"/qn NOADMIN=YES ALLCLIENT=YES" /S
However, when I try and install from SCCM, I get a 0x653(1619) error. I am kind of at a loss at this point. I can't see anything in the logs that can point to anything, but honestly I may be looking in the wrong logs. If the installation works in CMD, it should work in SCCM afaik.
The deployment is set up as a script installer, and I have the line copied above into the "installation program" field. "Installation start in" field is blank. Any ideas?
EDIT: I added logging and here are the results of the attempted install:
=== Verbose logging started: 1/11/2019 10:21:23 Build type: SHIP UNICODE 5.00.7601.00 Calling process: C:\Windows\SysWOW64\MSIEXEC.EXE ===
MSI (c) (58:C4) [10:21:23:811]: Resetting cached policy values
MSI (c) (58:C4) [10:21:23:811]: Machine policy value 'Debug' is 0
MSI (c) (58:C4) [10:21:23:811]: ******* RunEngine:
******* Product: C:\Windows\system32\config\systemprofile\AppData\Local\Downloaded Installations\{B8AAF34B-B4DF-4C47-8BDA-C424E745859F}\Borland Caliber Author Suite.msi
******* Action:
******* CommandLine: **********
MSI (c) (58:C4) [10:21:23:813]: Client-side and UI is none or basic: Running entire install on the server.
MSI (c) (58:C4) [10:21:23:813]: Grabbed execution mutex.
MSI (c) (58:C4) [10:21:23:872]: Cloaking enabled.
MSI (c) (58:C4) [10:21:23:872]: Attempting to enable all disabled privileges before calling Install on Server
MSI (c) (58:C4) [10:21:23:887]: Incrementing counter to disable shutdown. Counter after increment: 0
MSI (s) (4C:D0) [10:21:23:921]: Running installation inside multi-package transaction C:\Windows\system32\config\systemprofile\AppData\Local\Downloaded Installations\{B8AAF34B-B4DF-4C47-8BDA-C424E745859F}\Borland Caliber Author Suite.msi
MSI (s) (4C:D0) [10:21:23:921]: Grabbed execution mutex.
MSI (s) (4C:84) [10:21:23:962]: Resetting cached policy values
MSI (s) (4C:84) [10:21:23:963]: Machine policy value 'Debug' is 0
MSI (s) (4C:84) [10:21:23:963]: ******* RunEngine:
******* Product: C:\Windows\system32\config\systemprofile\AppData\Local\Downloaded Installations\{B8AAF34B-B4DF-4C47-8BDA-C424E745859F}\Borland Caliber Author Suite.msi
******* Action:
******* CommandLine: **********
MSI (s) (4C:84) [10:21:23:964]: Note: 1: 2203 2: C:\Windows\system32\config\systemprofile\AppData\Local\Downloaded Installations\{B8AAF34B-B4DF-4C47-8BDA-C424E745859F}\Borland Caliber Author Suite.msi 3: -2147287037
MSI (s) (4C:84) [10:21:23:992]: MainEngineThread is returning 3
MSI (s) (4C:D0) [10:21:23:995]: User policy value 'DisableRollback' is 0
MSI (s) (4C:D0) [10:21:23:996]: Machine policy value 'DisableRollback' is 0
MSI (s) (4C:D0) [10:21:23:996]: Incrementing counter to disable shutdown. Counter after increment: 0
MSI (s) (4C:D0) [10:21:24:000]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts 3: 2
MSI (s) (4C:D0) [10:21:24:024]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts 3: 2
MSI (s) (4C:D0) [10:21:24:025]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\InProgress 3: 2
MSI (s) (4C:D0) [10:21:24:025]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\InProgress 3: 2
MSI (s) (4C:D0) [10:21:24:025]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1
MSI (s) (4C:D0) [10:21:24:025]: Restoring environment variables
MSI (c) (58:C4) [10:21:24:029]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1
MSI (c) (58:C4) [10:21:24:029]: MainEngineThread is returning 3
=== Verbose logging stopped: 1/11/2019 10:21:24 ===
Installation still works when run from elevated command prompt outside of SCCM.
EDIT 2: I set the program to install with a GUI, and kicked it off via SCCM/Software Center. I was able to click through, and then it failed on extracting the files and running the msi with "This installation package could not be opened. Verify that the package exists and that you can access it, or contact the application vendor to verify that this is a valid Windows Installer package". Of course this makes me think that I should re-download the installer from the vendor and update the content in SCCM - HOWEVER the installer still works fine if I kick it off manually from the cmmcache directory so it doesn't make sense that the package itself is corrupted or in any way the problem.

This setup exe extracts an msi file into the (local) appdata of the user. (you can see this line in the log: C:\Windows\system32\config\systemprofile\AppData\Local\Downloaded Installations{B8AAF34B-B4DF-4C47-8BDA-C424E745859F}\Borland Caliber Author Suite.msi).
The problem is that the appdata of the system account actually lies within system32 and system32 is a wow redirected folder.
In general on a 64Bit Windows installation there is a copy for the programs (program files is the 64bit program files (x86) the 32bit folder, and the systme files (here system32 is the 64bit and syswow64 is the 32bit folder). The Wow64 emulation is responsible for checking if a program that is run is 32bit and if it tries to access one of the folders that it thinks is 32bit (on a 32Bit Windows system32 and program files exist as well and are the 32bit versions so some programs have this hardcoded) redirect this program to the respective other one.
Now as the systemprofile is a subfolder of system32 (unlike all other profiles which are stored in C:\users and are not wow redirected) it is redirected as well.
What seems to happen here is that your executable has some mechanism to extract the contents of it's msi to the "Downloaded Installations" folder in AppData and is a 64Bit executable (so its the system32\config\systemprofile). However for some reason it is configured to run the 32Bit msiexec.exe (you can see that in the first line of the log where it says C:\Windows\SysWOW64\MSIEXEC.EXE). When this file tries to access the path it is given by the exe wow translates the system32 path to syswow64 (although the msiexec.exe still thinks it is in system32) and the msi file can no longer be found. This never happens if you try manually because a normal user has the %localappdata% folder not redirected so 32bit and 64bit applications find it just the same.
Although there are methods to suppress the folder redirection it is not clear whether this would even work here because if msiexec.exe loads e.g. a dll from system32 and the redirection would be disabled it could crash, so the best idea here is to just extract the msi file (just start the installation manually and take it from the downloaded installations folder) and then deploy with the msi file directly. (If the exe installs any prerequisites before the msi it might be necessary to also install them)

Related

Win 2008 - MSI installer fails with firewall exception

OS: Windows 2008 R2
Zabbix Agent 2 - 6.2.5
As admin, when installing Zabbix Agent 2 MSI package with a PowerShell script, I'm getting what seems to be a firewall exception. That causes MSI installer to rollback.
The MSI installation log displays some errors related to Windows Firewall.
My PS script uses these parameters:
$argList = #('/norestart',
'/qn',
'/passive',
'/l*v',
"$zabbixDir\zabbixInstall.log",
'/i',
"$dirTemp\$msiAgentZabbix",
"INSTALLFOLDER=$zabbixDir",
"LOGFILE=$zabbixDir\zabbixAgent.log",
"SERVER=$proxy",
"SERVERACTIVE=$proxy",
"HOSTNAME=$hostname",
"ENABLEPERSISTENTBUFFER=1",
"PERSISTENTBUFFERPERIOD=1d",
"PERSISTENTBUFFERFILE=$zabbixDir\zabbixAgent.db",
"ALLOWDENYKEY=AllowKey=system.run[*]",
"HOSTMETADATA=`"windows $proxyname $metadata`"")
Start-Process msiexec.exe -Wait -PassThru -ArgumentList "$argList"
I've never had an issue with the MSI installer on Win 2008 VMs, but now, with other similar VMs, I'm getting these error messages.
MSI installation Log:
MSI (s) (18:F8) [09:57:32:457]: Doing action: WixSchedFirewallExceptionsUninstall
Action ended 9:57:32: RemoveEnvironmentStrings. Return value 1.
MSI (s) (18:40) [09:57:32:457]: Invoking remote custom action. DLL: C:\Windows\Installer\MSIC223.tmp, Entrypoint: SchedFirewallExceptionsUninstall
MSI (s) (18:34) [09:57:32:457]: Generating random cookie.
MSI (s) (18:34) [09:57:32:517]: Created Custom Action Server with PID 8076 (0x1F8C).
MSI (s) (18:C8) [09:57:32:777]: Running as a service.
MSI (s) (18:C8) [09:57:32:777]: Hello, I'm your 32bit Impersonated custom action server.
Action start 9:57:32: WixSchedFirewallExceptionsUninstall.
SchedFirewallExceptions: Component 'CONFIGFWx64' action state (1) doesn't match request (2)
SchedFirewallExceptions: No firewall exceptions scheduled
MSI (s) (18:F8) [09:57:32:787]: Doing action: RemoveFiles
Action ended 9:57:32: WixSchedFirewallExceptionsUninstall. Return value 1.
(...)
ExecFirewallExceptions: Installing firewall exception2 Zabbix Agent 2 listen port on port , protocol 6
ExecFirewallExceptions: Error 0x800706d9: failed trying to find existing port rule
ExecFirewallExceptions: Error 0x800706d9: failed to add/update port exception for name 'Zabbix Agent 2 listen port' on port , protocol 6
CustomAction WixExecFirewallExceptionsInstall returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
MSI (s) (F4:54) [08:00:09:652]: User policy value 'DisableRollback' is 0
MSI (s) (F4:54) [08:00:09:652]: Machine policy value 'DisableRollback' is 0
Action ended 8:00:09: InstallFinalize. Return value 3.
The oddest thing is that Windows Firewall is disabled on all VMs.
So, I can't see why that would be an issue for MSI installer.
If I start the MSI installer manually using its GUI, the installation works fine.
I'm not really sure the issue is the firewall, but that was all I could find.
Any idea?
Thank you all for your considerations.
Windows Firewall service was disabled on some hosts.
To bypass the issue, I enabled the service while maintaining the Firewall turned off.
After doing so, the installation was successful.
What still bothers me, is that, if installing with the traditional GUI, there were no issues. Only when installing with PS script it failed.
For now, by checking the Firewall service, I can use the MSI package with the script.

Msi is over write installation directory

I try to install Mysql.msi file in the F:\ drive using command below command:
$msiexec /a mysql-commercial-8.0.27-winx64.msi INSTALLDIR="F:", /qn, /l*v, install.log
In the MSI log file, I found the path changed automatically.
MSI (s) (E4:18) [14:37:45:516]: PROPERTY CHANGE: Modifying INSTALLDIR property. Its current value is 'F:'. Its new value: 'C:\MySQL\MySQL Enterprise Backup 8.0'.
Note:I am facing this issue in Azure and GCP server alone not in AWS windows server.

How to make Inno Setup installer keep temporary files either after installation completes or after VSTO installer completes?

I have Inno Setup installer (written before me) which extracts a set of VSTO files and starts VSTO MS Office addin installation then. It has a problem that upon extracting VSTO files into a temp folder and launching VSTOInstaller.exe it immediately displays Finish button. If the user clicks it, temporary files are deleted and starting the actual installation of VSTO addin in VSTOInstaller then results in "file not found" errors. I'm supposed to fix that (ideally, to have Finish button in Inno Setup installer appear only when VSTOInstaller spawned by it has finished execution).
VSTO package itself (a collection of "Application Files" folder, setup.exe and .vsto file) is created by ClickOnce Publish tool in Visual Studio. The package is digitally signed, etc.
I tried various options:
To not finish the Inno Setup installation until the process which opens .vsto file finishes (with waituntilterminated flag). Doesn't work, seems the process changes during opening the .vsto file, VSTOInstaller isn't the first process in the chain. Thus, Inno Setup waits only for the process which quickly passes execution to another process (VSTOInstaller) and then shuts down.
To not remove extracted files upon the installation (with uninsneveruninstall flag). Looks like it only works for uninstallation while removing temp files during the installation is somewhat different. I didn't find any way to keep the unpacked files intact after finishing the installation.
Currently .iss file looks like:
;---------------------------------------------------------------------
[Setup]
AppName=Outlook Addin
AppVerName=Outlook Addin 2.0
DefaultDirName={tmp}
DefaultGroupName=Outlook Sync Addin
Compression=bzip
Uninstallable=no
OutputBaseFilename=OutlookSetup
VersionInfoVersion=2.0.0.10
UsePreviousAppDir=no
;
;---------------------------------------------------------------------
[Files]
Source: "SourcesForExe\*"; DestDir: "{app}"; Attribs: hidden system; Flags: recursesubdirs uninsneveruninstall
;---------------------------------------------------------------------
[Run]
Filename: "{app}\OutlookAddin.vsto"; Parameters: "OVERRIDE=YES"; StatusMsg: "Extracting Outlook Addin installer..."; Flags: shellexec waituntilterminated
Originally, the installer run setup.exe rather than OutlookAddin.vsto. This caused setup.exe to launch VSTOInstaller.exe and immediately shut down. I thought changing to OutlookAddin.vsto (and adding shellexec flag) would fix that so that VSTOInstaller.exe would be launched directly by this method but but it didn't work. Turns out .vsto files are opened by vstoee.dll first.
Any idea how to either keep unpacked files (it's not a big deal that they will stay in temp folder) or somehow wait for all child processes spawned during the setup process?
If that matters, Inno Setup is 5.2.3, VSTO is built with Visual Studio 2015. Tested with Outlook 2010 and 2016.
{tmp} is setup's temporary folder, which gets deleted at the end. If you want to preserve the files, explicitly refer to the user's temporary folder using TEMP environment variable:
DefaultDirName={%TEMP}\outlook_addin_tmp
Though, it is a hack – the correct solution would be to wait for the VSTO installer to finish. I suggest you start the VSTOInstaller.exe explicitly. It should allow you to wait for it to complete
Something like this:
Filename: "{commonpf}\microsoft shared\VSTO\<ver>\VSTOInstaller.exe"; \
Params: "{app}\OutlookAddin.vsto"; \
StatusMsg: "Extracting Outlook Addin installer..."; Flags: waituntilterminated
I recently created this same as u required.
It is working fine for me, Start setup.exe then searches for VSTO process and binds exit event to it.
var process = Process.Start("Setup.exe");
Thread.Sleep(2000);
var processs = Process.GetProcesses().Where(i => i.ProcessName.Contains("VSTO")).ToList();
foreach (var item in processs)
{
if (item.ProcessName.Contains("VSTO"))
{
item.EnableRaisingEvents = true;
item.Exited += ExcelProcessExit; // this method will be executed after vsto completes it's installation or user cancels the installer.
}
}

File System Task from SSIS not working in SQL Server Agent (no errors)

I have a File system Task that does some ETL (moves some .txt files, copies to other directory, renames) between servers.
When I execute this package from Visual Studio, it works well, it copies the files from one server to the other, renames, and archives.
but when I set it with a job to run from the SQL Server Agent, it finishes without error, but it doesn't operate with any file, (no copy, no rename, no move) not even at the same server level.
I have given full permission to the SQL server agent service name for
the folders in which the files are located and have to be put.
The package runs in X64 and 32 bit mode without error.
Package security is set to "DontSaveSensitive"
Run64BitRuntime is set to "true"
this is the history log from running the job:
Executed as user: USERNAME. Microsoft (R) SQL Server Execute Package
Utility Version 12.0.2548.0 for 64-bit Copyright (C) Microsoft
Corporation. All rights reserved. Started: 3:08:56 PM DTExec: The
package execution returned DTSER_SUCCESS (0). Started: 3:08:56 PM
Finished: 3:08:57 PM Elapsed: 0.688 seconds. The package executed
successfully. The step succeeded.
The paths that I use for the package are all in the format:
\\ServerName\directory\subDir
My question would be, how can I know why the File System Task is not actually working?
I don't know how to check on logs more detailed to what I see on the SQL Server Agent to know what is actually happening, and if it's a permission issue I believe that I should see errors. I'm not sure about what is happening at this point.
Please let me know if there is more info I should add to help.
EDIT: I'm adding logging files from what I execute from VisualStudio (the one that works) and when the package is called from SQL Server Agent.
I will replace server names and usernames but I'll show what permits they have on different folders.
**MyUsername** = Username when I run from visual studio
**ORIGIN** = Origin server from where I copy the files
**DESTINATION** = Destination server where I put them and manipulate
**SqlServerAgent** = ServerAgent name
Log files from my computer when I run from visual studio (and the package operates with the files):
Log in Pastebin (VisualStudio)
and the log files for when I run from the SQL Server Agent:
log sql server agent
And information about the permits:
I found the issue, wasn't in the Parameters, or permit.
The issue was that the For Each Loop was pointing to a mapped drive instead of full qualified path like the rest of the folders, hence the For Each Loop wasn't finding anything.
However the permits were ok, just wasn't finding anything.

Installer created via Inno Setup, can't close applications during installation on Windows 10

I have created an installer for my application using Inno Setup. For a while everything works fine but recently installer failing to close explorer.exe (Windows Explorer) on Windows 10 during installation. Installer needs to restart it to replace existing context menu handler with new, but the more strange thing is that same installer works fine on Windows 8 and 8.1. Adding restartreplace flag does not helps.
I also noticed that the installer can't close currently running application (old one which needs to be updated) and like the previous problem the application can be closed in Windows 8 or 8.1 with same installer.
Here is the log from Inno Setup installer:
[11:22:34.819] Setup application started
[11:22:34.983] Setup version: Inno Setup version 5.5.9 (a)
[11:22:34.984] Original Setup EXE: ***
[11:22:34.984] Setup command line: /SL5="$C0928,15589089,85504,***" /DEBUGWND=$30464
[11:22:34.985] Windows version: 10.0.14393 (NT platform: Yes)
[11:22:34.985] 64-bit Windows: Yes
[11:22:34.985] Processor architecture: x64
[11:22:34.985] User privileges: Administrative
[11:22:34.987] 64-bit install mode: Yes
[11:22:34.991] Created temporary directory: C:\Users\Azat\AppData\Local\Temp\is-M4710.tmp
[11:22:37.584] RestartManager found an application using one of our files: Windows Explorer
[11:22:37.585] Can use RestartManager to avoid reboot? Yes (0)
[11:22:39.780] Starting the installation process.
[11:22:39.789] Shutting down applications using our files.
[11:23:09.944] Some applications could not be shut down.
[11:23:09.945] Message box (Abort/Retry/Ignore):
Setup was unable to automatically close all applications. It is recommended that you close all applications using files that need to be updated by Setup before continuing.
Click Retry to try again, Ignore to proceed anyway, or Abort to cancel installation.
[11:25:30.543] User chose Abort.
[11:25:30.544] User canceled the installation process.
[11:25:30.545] Rolling back changes.
[11:25:30.547] Starting the uninstallation process.
[11:25:30.548] Uninstallation process succeeded.
[11:25:32.049] Deinitializing Setup.
[11:25:32.071] Setup exit code: 5
I do not know why the installer is failing to close the applications.
But you can try the force option to work it around:
CloseApplications=force
I had a case that CloseApplications=force didn't help, and the only solution was to manually kill the running app.
I eventually used something like this:
[Files]
Source: "My Service 1.exe"; DestDir: "{app}"; Flags: ignoreversion; BeforeInstall: TaskKill('My Service 1.exe')
[Code]
procedure TaskKill(fileName: String);
var
resultCode: Integer;
begin
Exec(ExpandConstant('taskkill.exe'), '/f /im ' + '"' + fileName + '"', '', SW_HIDE, ewWaitUntilTerminated, resultCode);
end;
Source - https://stackoverflow.com/a/33776406/426315

Resources