Another Puzzling Repair Issue...
This is an involved story, but here goes...
We had a user at a pilot site attempt to utilize our installation, but the had redirected their My Documents to a UNC path and received a 1324 error. I believe I posted here about that a week or so ago. We worked around that by removing the involved component and we now let the application handle involved setting in this area at startup.
I believe I'm dealing with dirty machines now, but let me tell you what seems to be happening now.
When a non installing user, User2, logs in, they still receive the 1324 error during the repair install to place other user specific settings. My first thought was that the cached installation was bad. We re-cached the installation with REINSTALLMODE=vomus REINSTALL=ALL. That didn't make any difference so we initiated our application with another user, User3, and it seems to have gotten past that problem. So one question is what is going on with User2?
For User3, now a repair is repeatedly initiated when he/she logs in and the component that is 'broken' contains our Main executable. I'm not sure why this is occurring either. This potential customer is concerned about security so I don't know if they have any policies in place that would cause this behavior, but like I said, the machines are dirty as well.
I have not gotten a chance to look at logs of the repairs (hopefully they have logging enabled) as Support has been the first line of defense to this point, but plan to do so ASAP. I was just wondering it security restraints could possibly cause repairs for some reason.
I would also like to get a clean machine in place a the users site to test our lates install on a fresh slate.
I know this probably doesn't give anybody anything substantial to go on. Sorry and I hope to provide details soon.
so that the conversation will remain readable.