Software Deployment

Quick Fix: (not PERFECT, but maybe better than giving your user local admin rights)

Also, ask again here if you're not sure how do do this...

Also, please tell us whcih packaging tool (and version) you're using.

By the way, I also don't understand why MSIs get stuck in a loop like that - in my opinion, they should either work or fail - not get stuck looping.

Sounds like you need to identify which directories and/or registry keys your application is accessing.

Then, depending on which packaging tool you're using, there are ways to add permissions to them.

If your packaging tool does not have an easy way to do this, then I'll recommend 2 free command-line utilities which you can add to a custom action (I love 'em): RedDacle and XCacls, which affect permissions on reg keys and files/directories, respectively.

I hope this helps, and I can help you with the command-line structures with these utilities if need-be.

Good luck! :)

- Sean Roberts

Did you check the Event viewer to get the reason why it was repairing? use Regmon and Filemon to break down what needs rights and also try and see why it is repairing by check event viewer it will give the componet id and the files/reg entry its missing

MSI's auto repair themselves (like going to add/remove programs and selecting Repair) if one of its registered components is missing or changed. This will happen when you launch the application, it's happening at your user login because Office has some components that are launched at that time.

Now giving admin rights fixes it... hmmm... why would that happen... I'd check to see if your Office MSI has a registered component in a location that the user does not have access to. In that case the MSI will think a component is missing and initiate an auto-repair.

Also be sure that you do not have conflicts with other MSIs. If two MSIs each have, for example, a feature component with file with the same name & location but two different versions, both MSIs will try to "fix" the file to the version that they want. The two files will continue to fight over this file ad nauseum.

...hope that helps.

Hi,

You can try to give the admin rights to the Office 97 installation folder for all your Domain Users via File System GPO.

It helped me with some softwares.

I am having the same issue with other msi files. namely, visio and now office 2003. when the user has non-admin rights the msi is kicked off and the package "reinstalls". if they have local admin rights it opens just fine.

anyone have asny ideas how to resolve this? i have done a bit of searching to no avail. i am sure it has something to do w/ permissions of a reg key or file, i just cannot figure it out.

i have used regmon and filemon but nothing i have tried is fixing the problem. i have enabled the msi logging and check event logs as well. nothing i have tried has worked to fully resolve the issue and nothing is sticking out at this point as a possible lead.

any idea how to fix this?

thank you,
drew

Depending on the tool your using for distribution, you can also use the SYSTEM account to get the permissions you need.

The problem can happen if you have things like active shortcuts/files/folders. That change constantly. If you have an MSI/package/monitoring tool (SMS/Radia/EDM....) it looks for date/timestamp changes and want to "fix" these. If you turn off advertising of these shortcuts/files/folders.. your problem should go away.

Both Office and Visio do a small self repair for each new user that logs in and uses them. They are both populating Current User information and also profile specific folders.

If they require Admin rights to do this then your workstations have not had the Always Install with Elevated Rights policy applied to them. This policy must be set at both the workstation and user level and you can get more info on the Microsoft site about this.

sorry i didn't update this when i found my answer a while ago. the problem was that there was a file in the default user profile (usrclass.dat) that came from the image build process we haver here where they copy a profile over to the default user. it's basically a registry hive that a plain user did not have access to.

the solution was to delete the user's and default user's "usrclass.dat" located in Local Settings\Application Data\Microsoft\Windows of their profile folder.

thanks,
drew