Software Deployment

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.