Silent UltraEdit v17 IS install fails when run from SYSTEM accoutn
Hi, I am one of the scripters in my company. I script for MS SCCM software distribution. I have developed a script to install IDM UltraEdit v17; powershell is used for this. The script installs the software fine when running from my administrative account however when I run it from SCCM client it will fail, dropping in setup.log in source directory:
[ResponseResult] ResultCode=-3
As I already figured out in the forum it is relatively common error and possibly related to problem reading *.iss file. In my case file is correct and, as I previouslr written, install script reads it without problem when launched from administrative account, but not from SYSTEM account (used by SCCM).
I have checked the extracted command line used for installation in cmd.exe window, launched from my adm* account and from system account (I started it using "psexec -i -s cmd.exe" command). The error is reproduced: again only from command run as SYSTEM the install fail with error above. From Adm* account it is OK.
Command line is:
ue_english.exe /s /f1"C:\Windows\SysWOW64\CCM\Cache\GIN00111.8.S-1-5-21-1082477319-1605963434-1093625069-133267\install.iss" /v"LICENSEFILE=C:\Windows\SysWOW64\CCM\Cache\GIN00111.8.S-1-5-21-1082477319-1605963434-1093625069-133267\uedit32.spl" Any idea? Help is really appreciated.
It is difficult to determine what the cause of this behavior is without knowing how the setup was authored. There are a couple of basic possibilities. One, the path to the ISS file is invalid or inaccessible from the installation, causing the -3 result code (or it doesn't contain valid data for the installation it is passed to). The other possibility is this setup is authored to do something that does not work while running under the SYSTEM account.
For the ISS file, the path passed should be using C:\Windows\System32 as the setup.exe is 32-bit, so it will automatically be redirected to the 32-bit System32 (SysWOW64) folder. This assumes the data in the ISS is valid for the installation and does not change if the setup is run under different user environments.
To determine if the installation is doing something that causes it to not work when running in the SYSTEM account, a sample project needs to be created to determine if the behavior still exists. If the issue doesn't occur with a sample project, then the setup in question is likely the issue. Debugging through the script code may help to isolate the cause of the behavior in this case.
