Hello,

I have a sample package that I am trying to install from the service using CreateProcess something like this,


CreateProcess(
NULL,
"msiexec.exe /i C:\\SampleMsi.msi /quiet",
NULL, NULL,
FALSE,0 ,
NULL,NULL,
&si,
&pi);


I can see that it is getting installed at the correct location but I can't see its entry in Add/Remove programs list. If directly run, SampleMsi.msi gets installed correctly with an entry in Add/Remove program.
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
Kindly note that my service itself is getting installed using SampleParent.msi. Once installed and started, service calls CreateProcess(...
Answered 02/03/2010 by: milindsm
Blue Belt

Please log in to comment
0
Unless you get into MSI chaining (note: NOT nested MSIs, which is what you have here) which is available on in WI v4.0 and above, you cannot install an MSI from within another MSI.

Also, why not use the ServiceInstall and ServiceControl tables?
Answered 02/04/2010 by: VBScab
Red Belt

Please log in to comment
0
I think you are getting me wrong. I am using ServiceInstall and ServiceControl. The scenario is something like this,

1. Pkg_A.msi installs the service.
2. Once the service is installed and started, it installs Pkg_B.msi (using ShellExecute/CreateProcess) which is already there on the disk.
3. Now my problem is, Pkg_B.msi gets installed at the correct location but it does not appear in Add/Remove program list.
Answered 02/04/2010 by: milindsm
Blue Belt

Please log in to comment
0
Odd...in the log (you log your installs, right?), do you see the PublishProduct action having been run?Or, more likely, is the ARPSYSTEMCOMPONENT property present?
Answered 02/04/2010 by: VBScab
Red Belt

Please log in to comment
0
PublishProductis being run and its returning 1 but ARPSYSTEMCOMPONENT is not present in logs of inner MSI (Pkg_B.msi)
Answered 02/04/2010 by: milindsm
Blue Belt

Please log in to comment
0
Have you had a look in the registry in the key

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall

(Do a search of all subkeys for the ProductCode of Pkg_B.msi)

Also, does the service which installs Pkg_B.msi run under the Local System account, or a specific user account? I'm just wondering whether this may be a Per-User / Per Machine related issue (?)

Regards,

Spartacus
Answered 02/05/2010 by: spartacus
Black Belt

Please log in to comment
0
Hey,

It has an entry in the registry at,

HKEY_USERS\.DEFAULT\Software\Microsoft\Installer\Products\A92F8B789A4F4204C8373656404A2985\ProductName
HKEY_USERS\S-1-5-18\Software\Microsoft\Installer\Products\A92F8B789A4F4204C8373656404A2985\ProductName

Service is running under Local System account
Answered 02/05/2010 by: milindsm
Blue Belt

Please log in to comment
0
oops.... its at even more places...!!!!
Answered 02/05/2010 by: milindsm
Blue Belt

Please log in to comment
0
OK, well heres a method you could try to see if your Add/Remove Programs entry for the package is only visible to the Local System account.

1) Log on as Administrator
2) Click Start .. Run .. "cmd.exe" to start a command window
3) At the command prompt enter
[font="courier new"]sc create testsvc binpath= "cmd /K start" type= own type= interact
[font="courier new"]
4) Now type [font="courier new"]sc start testsvc
[font="courier new"]
5) This will launch a second command window running in Local System context
(ignore the error "The service did not respond to the start or control request in a
timely fashion" which appears in the first command window)

6) In the second command window, type the following

[font="courier new"]rundll32.exe shell32.dll,Control_RunDLL appwiz.cpl,,1

This should give you the Local System account's "view" of Add/Remove Programs.

Is your application listed in this view ? If it is, I don't think it should be ....

Regards
Spartacus
Answered 02/05/2010 by: spartacus
Black Belt

Please log in to comment
0
Hey.. I did that...!!! Pkg_B.msi as well as Pkg_A.msi both are not visible...!!!
Answered 02/07/2010 by: milindsm
Blue Belt

Please log in to comment
0
Anybody ......Somebody????
Answered 02/08/2010 by: milindsm
Blue Belt

Please log in to comment
0
JFYI... its working fine on XP
Answered 02/08/2010 by: milindsm
Blue Belt

Please log in to comment
0
Jeez...so only *NOW* we find out that your OS is Vista/Windows 7. Great.
Answered 02/09/2010 by: VBScab
Red Belt

Please log in to comment
0
cool... *NOW* I can expect the answer at the earliest .... [:)] Thanks in advance...!!!
Answered 02/09/2010 by: milindsm
Blue Belt

Please log in to comment
0
ORIGINAL: VBScab

Jeez...so only *NOW* we find out that your OS is Vista/Windows 7. Great.


But surely if it was Vista/Windows 7, the OP should have used the term "Programs and Features" rather than "Add/Remove Programs" ............................... well ...... should have [;)]

Spartacus
Answered 02/09/2010 by: spartacus
Black Belt

Please log in to comment
0
ORIGINAL: milindsm

cool... *NOW* I can expect the answer at the earliest .... [:)] Thanks in advance...!!!


*sigh*
Answered 02/09/2010 by: MSIPackager
Third Degree Black Belt

Please log in to comment
0
Can we look into the real issue please??? you can list my mistakes later on [8D]
Answered 02/09/2010 by: milindsm
Blue Belt

Please log in to comment
0
I have a question. Why do you need to run the MSI as a service?

If you run Sample.msi directly it appears in Add/Remove Programs or Programs and Features.
If you run it from within the service then it doesn't appear in Add/Remove Programs or Programs and Features.

Either your package is installing as per-user or it failing when run as the System account.

I assume that you are using logging and have looked at them thoroughly.
Answered 02/09/2010 by: michaelnowell
Second Degree Blue Belt

Please log in to comment
0
Why do you need to run the MSI as a service?
I am trying to install MSI package from service and NOT AS A service..!!! My service is checking for updates and the updates are in the form of msi.
Answered 02/09/2010 by: milindsm
Blue Belt

Please log in to comment
0
hey milind. thre is a property called ARPSYSTEMCOMPNENT.. If u set it to 0 then ur APP DOES NOT APPEAR IN ARP
if u set it to 1 then it appears in arp
Answered 02/09/2010 by: mitrokin
Senior Yellow Belt

Please log in to comment
0
thre is a property called ARPSYSTEMCOMPNENTPlease read the entire thread. This has been covered already. Also, FFR, the mere presence of that property means that no ARP entry appears. Its value can be anything: if it's present, no ARP entry.
Answered 02/10/2010 by: VBScab
Red Belt

Please log in to comment
0
Ok... What special can be done for Vista???
Answered 02/10/2010 by: milindsm
Blue Belt

Please log in to comment
0
Hey, I saw this line in Pkg_B.msi log file,


Determined that existing product (either this product or the product being upgraded with a patch) is installed per-user.


Is this causing the issue... if yes how should I go about it...???
Answered 02/10/2010 by: milindsm
Blue Belt

Please log in to comment
0
So.......you're testing an installation against an install which has already taken place?!? That is to say, Pkg_B is already installed? If so, wouldn't it be an idea to ensure that the install happens properly on a clean machine first?
Answered 02/10/2010 by: VBScab
Red Belt

Please log in to comment
0
Clean machine??? Installation of Pkg_B.msi goes smoothly if I install it separately (just double click and vvvooooo) is this what you meant??
Answered 02/10/2010 by: milindsm
Blue Belt

Please log in to comment
0
You posted a log fragment which indicates that Pkg_B is already installed. You should be testing the combination on a machine which has neither A or B.

EDIT:
Hang on...do A and B have the same ProductCode, by any chance?
Answered 02/10/2010 by: VBScab
Red Belt

Please log in to comment
0
Product code is different for both. Let me make the flow clear

1. I run Pkg_A.msi.
2. Pkg_A.msi installs a service on the machine (ServiceInstall & ServiceControl Table approach) and it is started immediately.
3. This service when started, calls CreateProcess with following arguments,

CreateProcess(
NULL,
"msiexec.exe /i C:\\Pkg_B.msi /quiet /l* C:\\Pkg_B.log",
NULL, NULL,
FALSE,0 ,
NULL,NULL,
&si,
&pi);

I have purposely kept Pkg_B.msi at C:\ for testing purpose.

Observations


  • Pkg_B.msi doesn't appear in "Programs & Features"
  • Pkg_B.msi is present at C:\Programs Files.
  • After verifying this, if I try to install Pkg_B.msi manually (double click), it doesn't show Remove/Repair Dialog. Does that mean the pkg is not getting registered properly ?
Answered 02/10/2010 by: milindsm
Blue Belt

Please log in to comment
0
I checked the System Event logs during installation time. There is some warning from Windows Defender Service saying

Windows Defender Real-Time Protection agent has detected changes.
Answered 02/10/2010 by: milindsm
Blue Belt

Please log in to comment
0
After verifying this, if I try to install Pkg_B.msi manuallyDoing that is pointless, since B is already installed. Uninstall it, THEN install it, THEN check ARP.
Answered 02/11/2010 by: VBScab
Red Belt

Please log in to comment
0
After verifying this, if I try to install Pkg_B.msi manuallyDoing that is pointless, since B is already installed.


There is no other way as B is not in the "Programs & Features" list and if I run Pkg_B.msi, ideally it should directly go to Repair/Remove but it goes to New Installation.

So whats happening is, B is not properly getting installed, its files are just being copied to "Program Files"
Answered 02/11/2010 by: milindsm
Blue Belt

Please log in to comment
0
F1 ! F1 !! F1 !!!
Answered 02/16/2010 by: milindsm
Blue Belt

Please log in to comment
0
We're going round in circles here. My opinion now is that to have a service which attempts to install an MSI is all wrong. To begin with, doing it that way, your MSI must live alongside the Pkg_A's EXE or, worse, in a hard-coded path.

Re-work Pkg_A so that it tests for the presence of Pkg_B and bombs with an appropriate message it it's not found. Change your doucmentation so that Pkg_B is installed first, or whichever is the correct order.
Answered 02/16/2010 by: VBScab
Red Belt

Please log in to comment
0
I am using hard coded path for Pkg_B.msi.

Even more simplified flow,

1. Pkg_A.msi has installed one service
2. The service is running smoothly.
3. When it (The service) comes across Pkg_B.msi at HARD CODED path (I am copying it manually at this moment for testing), it (the service) should install Pkg_B.msi
4. Service calls CreateProcess with application = msiexec.exe and args as HARD CODED Pkg_B.msi path (of course with appropriate switches)
Answered 02/16/2010 by: milindsm
Blue Belt

Please log in to comment
0
WE KNOW!

What I'm saying is that I think you've probably wasted enough time trying this way and that you need to re-think the entire approach, since the current one clearly doesn't work.
Answered 02/16/2010 by: VBScab
Red Belt

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