Hi all


I have an application which has setup.exe as a source media. I can run silently with switches /S /v/qn manually but when I am trying to install it through sccm 2007 it does not install the application. no short cuts on desktop, start programs or in add/ remove programe or no where.I can see sccm logs are fine giving result code as o. 

trying to find work around. After installing through SCCM 2007 MSI logs looks like

"MSI (c) (44:58) [14:24:49:947]: MainEngineThread is returning 3"
=== Verbose logging stopped: 7/31/2015  14:24:49 ===


Any permission issue.?

8 Comments   [ + ] Show Comments

Comments

  • Hi,
    sounds as if it the installation has a problem with the system account. Have you tried extracting the MSI and just installing the MSI? Start the exe manually, and before installing look in the %temp% directory for the extracted *.msi file. Once you have this you can then call it using the system account and perhaps supply a bit more information.
    • hi I am able to extract msi but it has same issue when I try to install .msi through SCCM. you mentioned
      "Once you have this you can then call it using the system account "
      how it is possible. I think I have tried that way also.
  • Like PAK said, it could be a System account issue. If you're familiar with it, try using psexec -s to run the silent install manually as the system account and see if it works.
    • I tried with psexec -s command to run .msi or setup.exe manually. it behaves same as installing through SCCM. does not install any shortcut or application etc. so its definitely a system account issue. so how to solve such type of issue? by adding any property in .msi or customising setup.exe? etc
  • have tried using psexec -s. and .msi or setup.exe does not work. it behaves same as installing through SCCM. so I think there is a definitely system account issue. so how to solve such issue? adding some property in msi or any customisation in setup.exe? thanks
  • ALLUSERS property might work? not sure...
  • also what will be the difference between system account and admin account?
  • The system account has less permissions than the Admin account, and does not "per-se" have a user context.
  • The system account actually has more elevated rights than the admin account - for example regedit running under the system account can show you security regkeys that are not available to an admin.
  • thanks for clarification. so based on logs any work around for this type of issue?
Please log in to comment

Community Chosen Answer

2
Look through the log again. Find the text 'Return value 3'. The half-dozen lines above that text will show you which action is failing.

Ensuring you set the ALLUSERS property to '1' is also good advice. It should be in all your MST templates.

BTW, I'd certainly NOT let a vendor EXE loose Without knowing *exactly* what it's doing. Sure, it's extracting and executing an MSI but are you sure it's not doing other stuff once the MSI's done with?
Answered 08/13/2015 by: VBScab
Red Belt

  • msi shows all users property set to 2. I changed to 1 but still fails.
Please log in to comment

Answers

1
Can you try with this command line

Setup.exe /s /v"/qn ALLUSERS=1"
Answered 08/14/2015 by: jagadeish
Red Belt

  • ok here is the thing. please guide me if I am on the right track.
    I tested successfully with simply through command line first like
    cmd---run as admin and execute "
    "\\psnva990\devpkg\CSI\QEG_BlockCross\_Backup\BlockCrossSetup.exe" /s /v"/qn ALLUSERS=1". it worked.

    Then I followed below steps to make sure it will work under system account or through SCCM.

    1) Run cmd.exe as Administrator

    2. Type the following command and press enter

    <PathToExe>\Psexec.exe -i -s -d cmd.exe

    3. You will get an another cmd prompt which is running in System Context

    4. Install your package through this new cmd prompt

    5. Check whether your package is getting installed without any issues or not.
    Here it does not install anything but it throws me error as "Access denied".

    Am I doing right things ?
    • Can you copy your package to local drive and then try to install it via System account, instead of installing it from the network location.
      • yes can run that way.....but not from network location.....
      • copied locally and it installed...
Please log in to comment
1

Use the same command line in SCCM

BlockCrossSetup.exe /s /v"/qn ALLUSERS=1"

When you advertise the package, in the "New Advertisement Wizard" ->Distribution Points

Select the following options

Download Content from the distribution point and run locally


Answered 08/14/2015 by: jagadeish
Red Belt

  • yes this option has been selected when I tested it, but seems it does not help for installation
  • This content is currently hidden from public view.
    Reason: Removed by member request
    For more information, visit our FAQ's.
Please log in to comment
0
Enable windows installer logging and run the exe installer.

Examine the logs that are created and it should identify which MSIs were run, from where and with what command line parameters passed to them.

Grab the MSIs and create an MST for each one and incorporate the relevant settings, plus your usual standards.

Test locally and if working ok, test through SCCM individually, deploying one by one.
If that works, then create an installation chain and retest the deployment.


Answered 08/13/2015 by: dunnpy
Red Belt

Please log in to comment
0
See the line few lines under the one like this: " ****** Command Line *******"? It says :[blah]BlockCross Client MSI -2147286037. Translating that last number to hex we get FFFFFFFF80030003. Drop the leading Fs - we're left with the classic DOS error 3 - Path not found. Something's gone missing.
Answered 08/13/2015 by: VBScab
Red Belt

Please log in to comment
0
These are the challenging setups! :-D

Anyway, all user = true and under system account still fails, right?

Does the application require any network access?
Did play around with Program Properties of the package?
Perhaps enable "allow users to interact with this program" can help, some setup somehow require a GUI.
Even if setup is unattended.

Last options are to debug the MSI and find out what is causing this block or repackage the MSI...(yes, very ugly).


Answered 08/18/2015 by: dedenker
Third Degree Black Belt

  • repackaging an already msi is I think not a good option. still it worked when Selecting the following options in SCCM

    "Download Content from the distribution point and run locally "
Please log in to comment
0
Extract the MSI and check, the shortcuts might not be part of the MSI and setup is designed to install the install shortcuts per user, check if the setup.exe is running any actions other than installing msi and creating shortcuts, extract the msi, create transform, add shortcuts and use property ALLUSERS=1.
Answered 08/18/2015 by: vinodmukka
Orange Belt

Please log in to comment
0
Like VBScab said,
run the MSI with logging (/L*vx). Perhaps you could post the log so we could have some more info?
It could be anything from a "strange" / non-conform custom action to impersonation problems....
Answered 08/13/2015 by: Pressanykey
Red Belt

  • hi here is the log which I get when I am running through sccm.




    === Verbose logging started: 7/28/2015 16:43:30 Build type: SHIP UNICODE 5.00.7601.00 Calling process: C:\Windows\SysWOW64\MSIEXEC.EXE ===
    MSI (c) (F0:04) [16:43:30:456]: Resetting cached policy values
    MSI (c) (F0:04) [16:43:30:456]: Machine policy value 'Debug' is 2
    MSI (c) (F0:04) [16:43:30:456]: ******* RunEngine:
    ******* Product: C:\Windows\system32\config\systemprofile\AppData\Local\Downloaded Installations\{A4FA9180-D2F5-4B7B-A6D1-B6B8DED93FD4}\BlockCross Client.msi
    ******* Action:
    ******* CommandLine: **********
    MSI (c) (F0:04) [16:43:30:457]: Client-side and UI is none or basic: Running entire install on the server.
    MSI (c) (F0:04) [16:43:30:457]: Grabbed execution mutex.
    MSI (c) (F0:04) [16:43:30:469]: Cloaking enabled.
    MSI (c) (F0:04) [16:43:30:469]: Attempting to enable all disabled privileges before calling Install on Server
    MSI (c) (F0:04) [16:43:30:474]: Incrementing counter to disable shutdown. Counter after increment: 0
    MSI (s) (10:A0) [16:43:30:478]: Running installation inside multi-package transaction C:\Windows\system32\config\systemprofile\AppData\Local\Downloaded Installations\{A4FA9180-D2F5-4B7B-A6D1-B6B8DED93FD4}\BlockCross Client.msi
    MSI (s) (10:A0) [16:43:30:478]: Grabbed execution mutex.
    MSI (s) (10:88) [16:43:30:479]: Resetting cached policy values
    MSI (s) (10:88) [16:43:30:479]: Machine policy value 'Debug' is 2
    MSI (s) (10:88) [16:43:30:479]: ******* RunEngine:
    ******* Product: C:\Windows\system32\config\systemprofile\AppData\Local\Downloaded Installations\{A4FA9180-D2F5-4B7B-A6D1-B6B8DED93FD4}\BlockCross Client.msi
    ******* Action:
    ******* CommandLine: **********
    MSI (s) (10:88) [16:43:30:479]: Note: 1: 2203 2: C:\Windows\system32\config\systemprofile\AppData\Local\Downloaded Installations\{A4FA9180-D2F5-4B7B-A6D1-B6B8DED93FD4}\BlockCross Client.msi 3: -2147287037
    MSI (s) (10:88) [16:43:30:479]: MainEngineThread is returning 3
    MSI (s) (10:A0) [16:43:30:480]: User policy value 'DisableRollback' is 0
    MSI (s) (10:A0) [16:43:30:480]: Machine policy value 'DisableRollback' is 0
    MSI (s) (10:A0) [16:43:30:480]: Incrementing counter to disable shutdown. Counter after increment: 0
    MSI (s) (10:A0) [16:43:30:481]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts 3: 2
    MSI (s) (10:A0) [16:43:30:481]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts 3: 2
    MSI (s) (10:A0) [16:43:30:481]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\InProgress 3: 2
    MSI (s) (10:A0) [16:43:30:481]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\InProgress 3: 2
    MSI (s) (10:A0) [16:43:30:481]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1
    MSI (s) (10:A0) [16:43:30:481]: Restoring environment variables
    MSI (c) (F0:04) [16:43:30:481]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1
    MSI (c) (F0:04) [16:43:30:482]: MainEngineThread is returning 3
    === Verbose logging stopped: 7/28/2015 16:43:30 ===
  • if wanted I can post SCCM logs too...
    • No need, looking at this, it is a bit more complex. I think that the boot strapper (the exe that is installing the nested / transactioned msi's) is having problems. Have you tried extracting the MSI'S and installing them individually?
      • yes I tried to install .msi and same problem as with setup.exe. works manually or through command line but not through SCCM...
Please log in to comment
Answer this question or Comment on this question for clarity