I am getting ready to deploy Avaya Contact Center Express 5.0 via SCCM. I can successfully deploy it to XP. I'm using the setup.exe, passing in my setup.iss I recorded, and then passing in a transform on the command line. On Windows 7 X64, I cannot get it to install with the system account via SCCM. The install just dies. I took it out of silent mode because procmon/msi logs weren't showing any errors or anything missing. Deploying it in non-silent mode throws error 1628 towards the beginning. It is using ISSscript 10.5, and I've taken out the "run as" key so that it won't try to use the logged in user's rights to install. Here's the funny part. If I use my exact same deployment running from an elevated command prompt (not system account), it installs fine. If I uninstall the app and then run the one from SCCM with the system account, it installs fine with the system account. I've combed the differences in procmon and the msi logs and cannot see anything different between the two situations. I'm at a loss here. I've also tried turning off UAC, and setting software restriction policies to allow admins to install but they didn't make a difference, and running it in compatibility mode. I've scoured the internet for answers on error 1628, but none of the solutions have worked or are related to error 1628 with a local system account.

Does anyone have any ideas why my install will install with the system account on XP, but not Win7? Why would it work on Win7 with the system account after I'd manually installed/uninstalled it? I'm out of ideas...

Thanks in advance.
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
If you are still having troubles with this, it may be a dcom error with your isscript install, although I believe you may have addressed this.... try this post ~
[link]http://itninja.com/question/blackberry-3.6-must-run-setup.exe300&mpage=1&key=穄[/link]

Also check your installer versioning in the msi, maybe specing the wrong version for the OS. Are you using a transform file for the Avaya install?

My 2c
Wayne
Answered 02/21/2011 by: WayneB
Blue Belt

Please log in to comment
0
I've checked the APPID key and the IDRIVER keys don't have the Run As key in them. I'd removed them from the ISSCRIPT msi. I also looked at the MSI and the schema is set to 200 with no install conditions. I am using a transform but it does the same thing without a transform. The thing is that it installs fine with the system account on XP. And, after I manually install/uninstall, it will install fine with the system account on Win7. That's why I'm so confused. I can't see any differences before/after a manual install as to why it would then work via SCCM with the system account... Let me know if you have any other thoughts and thanks for the assistance.
Answered 02/22/2011 by: tgakk
Yellow Belt

Please log in to comment
0
I maybe totaly on the wrong track here, but I have had 2 deployments, one worked on win7 and not xp and the other, the opposite. Both were due to the reason that sccm did not resolve paths correctly. Using a .bat file containing d%~dp0 was the fastest way to get them going, there are also scripts.
Answered 02/22/2011 by: admaai
Orange Senior Belt

Please log in to comment
0
Thanks for the reply. I had the issues with the paths via SCCM at first, but changed that before I made my initial post here as part of my testing. I am passing in the full paths for the setup.exe, transform, and setup.iss file. I have verified that they are correct. The paths don't have any spaces so don't need to escape quotes. If I just run my deploy script that runs the command line manually, it works great. I just can't get it to work via SCCM on Win7 only. Works fine on XP.
Answered 02/22/2011 by: tgakk
Yellow Belt

Please log in to comment
0
Identical issue here, however with a different application.
Installing on Win7 x64.
Have you had a look at the MSI logs? I wonder if you are also getting leaked MSIHANDLEs

The following occurs when installing under system account on our Win7 x64 SOE (no problems installing under system account on vanilla Win7 x64):
setup.exe is executed
MSI and Installshield support files are extracted
When the Installshield progress dialogue states "Preparing to install" - error 1628 appears.
Setup.exe and msiexec.exe terminate.
I'm left with a process named ISBEW64.exe that will not end until I manually end it.

MSI Verbose log file ends with the following:
-----------------------------------------------------------------------
InstallShield Script opened successfully
Leaked MSIHANDLE (10) of type 790541 for thread <thread id of setup.exe>
Leaked MSIHANDLE (9) of type 790537 for thread <thread id of setup.exe>
Destroying RemoteAPI object
Custom Action Manager thread ending.
Verbose logging stopped
------------------------------------------------------------------------

When running setup.exe as the logged in admin account the installation completes without error.
setup.exe is executed
MSI and Installshield support files are extracted
When the Installshield progress dialogue states "Preparing to install" - VC++ 2005 Redist is installed
(when running as system account, it errors before VC++ 2005 Redist is installed)
Installshield Setup Wizard is displayed.
There are no Leaked MSIHANDLEs in the verbose log


I have no issues installing under system account on a vanilla Win7 x64 OS. Only happens on our SOE.

In rare cases I've managed to get it installing as System account by performing a combination of the following, however the results are not reliable enough.
1. unregister and re-register msiexec
2. Set InstallerLocation to c:\windows\syswow64\ under HKLM\Software\Microsoft\Windows\CurrentVersion\Installer
3. Switch between launching setup.exe from a 32bit cmd.exe and a 64bit cmd.exe

Switching off AV and other security software has not resolved the issue.

Leading up to the error, the MSI verbose logs of a succesfull install and failed install are the same

Nothing is standing out as considerably different in procmon between a succesfull install and failed install

The fact that the software installs as system account on vanilla Win7 x64 suggests that there is either a GPO on our SOE causing the issue or some other software/service.
I'm getting close to the point that I'll need to start using the process of elimination until it works, but that is going to be a long and cumbersome exercise.

I hope you manage to sort it out, Interested to know if you are getting leaked MSIHANDLEs in your MSI logs too.
 

Answered 07/31/2017 by: moezus
White Belt

Please log in to comment
Answer this question or Comment on this question for clarity