/build/static/layout/Breadcrumb_cap_w.png

Need more experienced or fresh eyes.

I am trying to package a series of nested executables, into an msi; per company requirements, but I am running into a situation. I don't know if I ate too many paint chips, or I am too "crazy"; but I am not seeing the issue. The application is Remedy ver. 7.5.0, and it will install and run perfectfly under my account.

When I create a new, locked-down user, and log on as that test account, any of the three shortcuts invoke a repair. If I go directly to the files and execute them, they are fine. I have removed any reference from the hkcu, and changed the paths of the advertised shortcuts. I have even resolved the component and tables to the correct pathing; but it still invokes that P.I.T.A. repair. I am crazy right now, this should be so open and shut, but I cannot do it. I would love to put the .wsi up here, but I cannot.

Any help is appreciated, it is driving me insane....

0 Comments   [ + ] Show comments

Answers (10)

Posted by: naveen.packager 13 years ago
Green Belt
0
I dont know if i have understood you correctly, but as per my understanding u mean to say that u dont want to have self repair when launched the shortcut. If it is wright then why dont you make u r shortcuts non advertised. I am sorry if i have not understood u r query correctly.
Posted by: nspatial 13 years ago
Senior Yellow Belt
0
No, you have understood. I do not want the self-repair to start when a new user logs-in. However, I have tried un-advertising all the shortcuts (2 of them), and the problem remains. My company wants the registered short cuts, so it can't be this.
Posted by: naveen.packager 13 years ago
Green Belt
0
Ok, I am hoping that as per your comapny standards u need advertised shortcuts and u dont want a self repair when the new user logs in. Am i wright?

If so the check the event viewer and see which component is triggering self repair.I think u have files in user profile, if they are then u can use active setup to copy those files to new user when logs in.
Posted by: nspatial 13 years ago
Senior Yellow Belt
0
Naveen, thank you for your help, I do appreciate it. I have never had the use the ActiveSetup, so I don't understand how it could be used to solve the issue. The component tables have all resolved, with no errors. I have nothing going in the HKCU, that is why it is so hard, even the event log gives me very little info.
Posted by: admaai 13 years ago
Orange Senior Belt
0
You have to gather information. Does the self repair start with new Admin user as well? If yes then enable windows installer logging in registry for the test computer and check the logs. If only locked down users trigger the self repair then you have permission issues, Luabuglight should give you the answer.
Posted by: mekaywe 13 years ago
Brown Belt
0
Is it a repackaged msi? Then I think some machine registry keys might be present in your package. Check all CLSIDs, Interfaces, Typelibs and try to prune up your msi.
Posted by: nspatial 13 years ago
Senior Yellow Belt
0
regretfully no, it is not a repackaged msi. Nested exe's with scripts, and archives. Now I have it almost done, only one icon now, when in a locked down desktop, keeps pulling repair. On another admin account, it pulls the repair once, and then is fine. When locked down, it continually repairs on ever execution of that one shortcut.
Posted by: bearden3 13 years ago
Purple Belt
0
regretfully no, it is not a repackaged msi. Nested exe's with scripts, and archives. Now I have it almost done, only one icon now, when in a locked down desktop, keeps pulling repair. On another admin account, it pulls the repair once, and then is fine. When locked down, it continually repairs on ever execution of that one shortcut.

Random thoughts - hopefully, something with help or put you in another direction to solve the problem.

You say it is a collection of exe's, scripts and archives. Did you do your homework and manually install everything in the order is should be installed first? If not, I'd suggest that you do that as it could help you figure out where the problem lies, testing the app after each piece is installed.

Just for grins, how about doing a capture on the entire install (you have WPS, so use that) and then looking at the registry to HKCU keys?

Nowadays, exe-based installs usually have an MSI embedded in the setup. Have you tried to run a setup (install, etc.) /a (for admin install) and see if you get the extracted files? The worst thing to happen is that you get the install starting up (because it might ignore the switch).

Have you tried running the setup and when the first configuration screen comes up then go looking in the %temp% folder for the setup files? Temp points to various places so you might need to search your Documents and Setting folder, Users folder, c:\temp, or c:\windows\temp (as examples).

Can you change the order that the installs are done? I could be that app1 creates a key, then later, app3 changes the key, and when app1 is run, it envokes the repair? And if app3 is then run, it could cause yet another repair to put things back for app3 and so on.

You also said orginally that there were 3 shortcuts then said there were only 2 shortcuts and lastly said that you reduced it to one shortcut.

Without you doing some other test scenarios to post, my guess is that you'll be going around and around with this one.
Posted by: naveen.packager 13 years ago
Green Belt
0

I am trying to package a series of nested executables, into an msi;


regretfully no, it is not a repackaged msi. Nested exe's with scripts, and archives.


Are you testing the packaged msi or the original exe?

I think you are testing the packaged msi.

When locked down, it continually repairs on ever execution of that one shortcut


As admaai stated, turn on logging in registry and check the log file.What does Event Viewer says? If you are not sure then post the log file(use code tag) . You can get some help from any one.
Posted by: anonymous_9363 13 years ago
Red Belt
0
Did you validate the MSI? It sounds to me like you have a mix of machine and user components in a feature and the machine components cannot be repaired because the user has no rights to the resource. The Event Viewer will identify the component ID being repaired and you can work backwards from there.

It might also be that, even though the resource is a user resource, it might be controlled by permissioning. It's common to have, for example, the HKCU branch which controls which icons appear in Control Panel locked down. Ditto for things like whether the screen saver is password-enabled.
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
 
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