This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- ServiceInstall & ServiceStart failing in one VM environments
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 16, 2008
06:19 PM
ServiceInstall & ServiceStart failing in one VM environments
Hi all,
I have a new Basic MSI installer (version 2.Y) that uses the Install NT Services and Control NT Services to take care of configuring our service.
The service gets installed and started fine everywhere except in one of our VMWare ESX Server environments where the service does not get installed and started during installation. If I go back a to the previous 2.X release, that also uses the same mechanism for installing the service, it works fine. It also works fine in other ESX environments.
I ran the install the 2.X and 2.Y installs with verbose logging for comparison and discovered that there is no indication that the 2.Y install is even trying to install and start the service. I would have expected at least some kind of error in the logs.
Anyone have any idea why: a) what might be the cause of the service will not being installed on this one VM and b) why the ServiceInstall and ServiceStart info isn't being logged?
TIA
Ken
I have a new Basic MSI installer (version 2.Y) that uses the Install NT Services and Control NT Services to take care of configuring our service.
The service gets installed and started fine everywhere except in one of our VMWare ESX Server environments where the service does not get installed and started during installation. If I go back a to the previous 2.X release, that also uses the same mechanism for installing the service, it works fine. It also works fine in other ESX environments.
I ran the install the 2.X and 2.Y installs with verbose logging for comparison and discovered that there is no indication that the 2.Y install is even trying to install and start the service. I would have expected at least some kind of error in the logs.
Anyone have any idea why: a) what might be the cause of the service will not being installed on this one VM and b) why the ServiceInstall and ServiceStart info isn't being logged?
TIA
Ken
(4) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 17, 2008
05:01 AM
Ken,we just got the same problem,i almost sure it is beacuse the permission set for th VM user.
Same installation work fine on none VM machines.
Try to take alook at the event viewer.
also i move to use windows installer tables and only after that got some error message which helped me to figure out it was permission issue
Same installation work fine on none VM machines.
Try to take alook at the event viewer.
also i move to use windows installer tables and only after that got some error message which helped me to figure out it was permission issue
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 17, 2008
08:46 AM
tomerdr wrote:
Ken,we just got the same problem,i almost sure it is beacuse the permission set for th VM user.
Thanks. A permissions issue had also crossed my mind. I'll pass this info along to our VM gurus.
Ken
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 19, 2008
09:38 AM
Hi all,
Turns out that the real problem was not a ServiceInstall or ServiceStart issue.
An updated third party DLL used by one of our EXEs in a Custom Action is causing the EXE to fail and start the roll back before the ServiceInstall and ServiceStart are even attempted.
The failure appears to be due to Side-By-Side errors causing our utility to actually crash and when I compared WinSxS directories of the VMs, there were omissions on the troublesome VM compared to other VMs that worked fine.
So, its something with our binaries.
Ken
Turns out that the real problem was not a ServiceInstall or ServiceStart issue.
An updated third party DLL used by one of our EXEs in a Custom Action is causing the EXE to fail and start the roll back before the ServiceInstall and ServiceStart are even attempted.
The failure appears to be due to Side-By-Side errors causing our utility to actually crash and when I compared WinSxS directories of the VMs, there were omissions on the troublesome VM compared to other VMs that worked fine.
So, its something with our binaries.
Ken
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 19, 2008
09:45 AM
First I'd try to get rid of the EXE CustomAction. What does the CA do? Is it really needed, is there a better way to do it?
Languages like C++/InstallScript/C#(via DTF) can host CA code better to allow for improved error handling, communications, ectera. You might also be able to eliminate the dll dependency.
If none of that can be done, consider deploying the DLL as a setup prerequisite so that it's properly deployed to the SxS before your MSI starts. You should also write a corrosponding AppSearch/LaunchCondition to block the install if that isn't done. Remove the DLL from your main install since it's predeployed. Now when your EXE runs, it should work.
Languages like C++/InstallScript/C#(via DTF) can host CA code better to allow for improved error handling, communications, ectera. You might also be able to eliminate the dll dependency.
If none of that can be done, consider deploying the DLL as a setup prerequisite so that it's properly deployed to the SxS before your MSI starts. You should also write a corrosponding AppSearch/LaunchCondition to block the install if that isn't done. Remove the DLL from your main install since it's predeployed. Now when your EXE runs, it should work.
