/build/static/layout/Breadcrumb_cap_w.png

Software Deployment Question


Service Starts - Causes MSI to Self Repair (HKEY-Current-USER Setting missing)

06/15/2010 3884 views
Guys,

I have a snapshotted MSI that installs a service. I did the snapshot in InstallShield 2008

This service runs in System context.

Every time this service starts the MSI self heals, a component with a key path in the HKEY_Current_User REg hive is the culprit.

I can only assume that the service in system context is raising the self repair in the same context and "System" doesn't have a HKEY_Current_USER Hive...

I have never seen this before....so I am wondering if anybody else has?


To try to resolve it I have tried to isolate the service elemtns in a seperate feature that is a child of a parent feature that has all the current user setting in...

Any help much appreciated.

Thanks.
0 Comments   [ + ] Show comments

Comments


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

All Answers

0
What kind of service puts stuff in the user profile?!? Have you asked the vendor? Are you sure you haven't captured something unrelated to the service? Have you tried moving the entry to HKLM?
Answered 06/15/2010 by: anonymous_9363
Red Belt

0
It's not the Service writing to CurrentUser..

The service calls a number of Dll that have COM info (advertising) and these are the entry point into the package's self healing.

I am working on getting around it be re-organising my features...moving the service related components into an isolated feature on the same level as the feature that contains the current user details...

Will post how I get on.
Answered 06/16/2010 by: wynnem
Orange Belt

0
So you're installing a service, per-user? That's the principal reason that the healing would attempt to put stuff into HKCU. Either that, or the relevant Registry.Root cells in the package is set to 1...
Answered 06/16/2010 by: anonymous_9363
Red Belt

0
I am not aware how you have captured the service, but if I just think to resolve this issue only, then I will suggest you to use Activesetup in your package.
Answered 06/17/2010 by: Yaduveer
Orange Senior Belt

0
What probably happens is the service uses one of the advertised DLLs in your package, this triggers the repair and indeed, since the service runs in SYSTEM something goes wrong finding the correct CU hive. The event log should have data on exactly what component is missing what data.

Like Yadu said, you can always remove the offending component and replace it with Active Setup

PJ
Answered 06/17/2010 by: pjgeutjens
Red Belt

0
I resolved the issue by adding the offending components into an isolated feature...
Answered 08/09/2010 by: wynnem
Orange Belt

 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ