Hi All,

Here's my situation in a nutshell... Both installing users are Admins on the target machine. User1 installs our software and is able to initiate the software without repair. User2 logs into the system and initiates our application (from an advertised shortcut), which initiates a repair install to write various user specific items.

Now, we switch back to User1. When he/she launches the install, a repair is initiated. After checking the Event Log, the process detects that a user item from User2's profile is missing. Why in the world is this occuring?

Is the repair process initiated by User2's initial login somehow not registered as the install process 'owner'.

If I log on as User2 and initiate our app at this point, a repair is once again initiated as a User1 piece is missing. What in the world gives?

I guess I should mention that I'm testing on a Win 7 x64 system with UAC set as the highest level (the only level above the default I believe).

I am making a push to remove user specific items from our install in a move to a per machine installation. Our application could/should then handle user specific settings on launch.

If anyone can help me sort this out and determine if there is any way around this behavior or if it is typical Windows Behavior I would be more than appreciative. I wonder if it is because I changed our shortcut to advertised a while back.

Thanks in advance!
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

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

Answers

0
Capture the items that are being changed. Discover where the problem in the changes are (likely a hardcoded path or something that requires better use of a variable). Create some means to impliment them (exe, msi, script, etc). Create an Active Setup to apply the changes per user at login.
Answered 11/30/2011 by: jmaclaurin
Third Degree Blue Belt

Please log in to comment
0
There's no difference if the launching shortcut is Advertised or not. The behavior is the same.

Why, when the apps are repaired, are they then broken for another user that was already functioning?
Answered 11/30/2011 by: Superfreak3
Black Belt

Please log in to comment
0
The item missing is...C:\Users\User1\Documents\My MyApp WorkArea. This comes from a component whose destination is set as [PersonalFolder]My Adept WorkArea in InstallShield.

This is what appears in the Event Log as the trigger for User2's repair. Why is it looking across to User1's information.

I would rather have user specific items removed from the install then bothering with Active Setup. I don't want to compound the install process further, I want to simplify it. I've read recommendation that an install should be Per Machine or Per User. We can't go the Per User route as we need some things in HKLM and protected areas of the file system.

Also, isnt the purpose of Active Setup to launch a repair when no entry point is available to the user? A repair is firing for me with both an advertised and non-advertised so what will Active Setup get me?
Answered 11/30/2011 by: Superfreak3
Black Belt

Please log in to comment
0
Per Machine vs Per User are not the same when it comes to coding within the application. Unless you are willing to go through and rewrite the vendors code (or MSI) and subsequently negate any type of support from the vendor, I would suggest you work with the Per User install. Make an MST which removes the user specific changes and then add them to a MSI/EXE/script. Call the MSI/EXE/script to make the changes required by the original MSI then also use it in an Active Setup.
Answered 11/30/2011 by: jmaclaurin
Third Degree Blue Belt

Please log in to comment
0
ORIGINAL: jmaclaurin

Per Machine vs Per User are not the same when it comes to coding within the application. Unless you are willing to go through and rewrite the vendors code (or MSI) and subsequently negate any type of support from the vendor, I would suggest you work with the Per User install. Make an MST which removes the user specific changes and then add them to a MSI/EXE/script. Call the MSI/EXE/script to make the changes required by the original MSI then also use it in an Active Setup.


Not quite sure what you mean, but this. We are the vendor so we create the .msi. My ultimate goal is to remove all user specific components from the install and make it a true Per Machine installation. Then, we will rework code in our application to handle any needed user specific settings from items placed in Common App Data or somewhere in HKLM. The only real downside I see to this is creating a widget to run during uninstall that will clean all user areas. It would rid us of repair installs altogether. I should say it will rid us of the repairs we are used to seeing through use by non-installing users. Repairs may still occur, but after modifications, the per machine install/app will truly be 'broken'.

Until the time of rework, we are presented with the problem described initially. I just don't understand why Windows Installer looks to another User's area for installed components under the current, app initiating user. I can repeatedly toggle between the two users and a repair is always fired. Once repaired, it should be repaired as far as I'm concerned. Initiating our app from User1 should not trigger a repair because something in User2's profile is 'missing' or 'inaccessible'. I just can't figure out that logic. I would think it has to be something in our authoring of the installation package, but I wouldn't be surprised by this backwards logic from Microsoft.

When it comes to our authoring, I don't know what else it could be outside of marking certain user-specific items as component keys.

Per User installations won't really work for us since we have to place items in HKLM and restricted areas of the file system.
Answered 11/30/2011 by: Superfreak3
Black Belt

Please log in to comment
0
Presumably, in the original log of the install for User2, [PersonalFolder] resolved to the correct folder?
Answered 12/01/2011 by: VBScab
Red Belt

Please log in to comment
2
All I can offer is this. Almost everyone that posts on this site does so to fix problems with poorly designed software and/or documentation. If you don't want to see your product or company's name listed in a title of a forum post, FTLOG follow best practices and think of the end user, not what YOU want. Its the end users that will be using your product in ways you haven't considered yet. Make your product capable of handling situations such as silent installs, multiple users on a single machine, variables instead of hard coded pathes, flexibility in deployment methods, use in closed or dark networks (ie, no contact ever with the outside world) and get your product signed to make everyones life easier.

Don't take this as directed as you personally, but a plea from someone that has been deploying/packaging software for 12 years and has had my fill of crappy software and vendors that just don't GAS.
Answered 12/01/2011 by: jmaclaurin
Third Degree Blue Belt

Please log in to comment
0
Believe me, that is what I'm trying to do. I try to tell development that I am simply dumping what they tell me is needed by the application and to locations they specify. One even stated the our file system structure is based on Windows 3.1. We still even write 'stuff' to the root of C:\!!! I hear everything you are saying about making things as seemless for the customer as possible. That is why I want to move away from writing user specific items during the install. We need admin rights for install now anyway so why not make it a strictly Per Machine install. User specific info should be handled by the app itself in this instance, I feel.

In short, I'm trying, but old timers here are resistent to change. They're starting to get it now that security is tightening.
Answered 12/01/2011 by: Superfreak3
Black Belt

Please log in to comment
0
ORIGINAL: VBScab

Presumably, in the original log of the install for User2, [PersonalFolder] resolved to the correct folder?


Why wouldn't it resolve properly. If it resolves correctly for one user, why wouldn't it for every user. That, I would think would be a Windows Installer shortcoming.
Answered 12/01/2011 by: Superfreak3
Black Belt

Please log in to comment
0
everything in the directory table should resolve properly on repair/install/remove whatever.
BUT maybe the vendor has some custom action in the msi filling the path.
maybe the custom action is not run during user repairs (because of conditions).

so take a look at the custom action table.
also try to get a verbose logfile out of the installation and repair and post everything relating to that path in it.
Answered 12/02/2011 by: weberik
Yellow Belt

Please log in to comment
0
ORIGINAL: Superfreak3

The item missing is...C:\Users\User1\Documents\My MyApp WorkArea. This comes from a component whose destination is set as [PersonalFolder]My Adept WorkArea in InstallShield.
This is what appears in the Event Log as the trigger for User2's repair. Why is it looking across to User1's information.

You are expecting the target directory to be dynamic (to be reevalutated for each user that launches the app) but it is not. When User1 installed the app, [PersonalFolder] evaluated to User1's Documents folder, and that's what's cached when the installation is complete. When User2 runs the app, it sees a key path missing (possibly a CreateFolder entry for the above directory?) and so proceeds to repair the app based on the cached information, which is still pointing to User1's profile. There are special ways of dealing with per-user information in a per-machine installation. This subject has been covered extensively in this forum.

I would rather have user specific items removed from the install then bothering with Active Setup. I don't want to compound the install process further, I want to simplify it.
Good to hear. And your thoughts on removing user-specific information from the package and making it the responsibility of the app sounds valid, especially since you're talking about data under the Documents folder. It really doesn't seem appropriate for an app to install anything under the user's Documents folder. Let the app take care of that at run-time.

I've read recommendation that an install should be Per Machine or Per User. We can't go the Per User route as we need some things in HKLM and protected areas of the file system.
It's technically possible to go both ways, if your app supports it. I'm not sure I would bother, though. IMO, per-user installations are for home users, per-machine installations are for managed users.

My ultimate goal is to remove all user specific components from the install and make it a true Per Machine installation. Then, we will rework code in our application to handle any needed user specific settings from items placed in Common App Data or somewhere in HKLM.
Again, this sounds valid and I like it.

The only real downside I see to this is creating a widget to run during uninstall that will clean all user areas.
You shouldn't clean up anything in the user area on uninstall. This goes against best practice. Never delete user-created data and settings. (Plus, the data might not even be local to the machine!) If the user is merely reinstalling, they should not lose their preferences and data. If they are upgrading, the new version should be able to read the old data and settings and be able to migrate them.

If absolutely necessary to separate application settings between versions (maybe because you're changing the format of the settings files or some major change), consider having the new version store settings in a new, versioned directory and migrate from the old directory. For example:

MyApp v1.0 writes user settings to <AppData_Local>\Vendor\MyApp\1.0\
MyApp v2.0 writes user settings to <AppData_Local>\Vendor\MyApp\2.0\
etc.
Maybe MyApp v2.0 looks for settings in MyApp\1.0 on first-time launch and migrates settings to the 2.0 folder.

In general, though, if the app can safely reuse the same directory with each upgrade without difficulty and the developers remain consistent with settings file format and filenames, then consider going that route. It's entirely up to the development team and how the app is maintained.

Also, be sure to reference Microsoft recommended development practices such as Windows Logo documentation (or whatever they're calling it now).

(Hope that wasn't too muddled, especially when I switched from talking about user data to application settings.)
Answered 12/02/2011 by: mazessj
Blue Belt

Please log in to comment
0
Actually, it might be better if you could have the software perform its final configurations for user specific settings at time of first launch (which is what I think you are working towards?), because it frees up the installation to be greatly simplified and can be made pretty vanilla in the end. The difficult part will be to convince your developers. It sure would make packaging and deployment easier. Especially if you design it so that something like an Transform or an Active Setup could be used to perform much of that first launch customization prior to launch.
Good luck!
Answered 12/02/2011 by: jmaclaurin
Third Degree Blue Belt

Please log in to comment
0
All excellent responses and even better, they contained what I really wanted to hear!!

My feeling now is to spend most of my energy pushing for the Per Machine installation changes. I'm sure I'll get some pushback from the 'old time' Devs, but that won't deter me. In my opinion, the changes won't be that major and shouldn't have a huge impact, but some Devs will think they'll be re-engineering the entire product.

Since the repair of the two different user instances isn't really a show stopper, I'm not that concerned about tracking down the specifics of the scenario. Once the repair completes, the user is off and running. Also, we don't have many customers that have systems that are shared between different users, so that makes the issue even rarer, I guess. If I have some free time in the next couple of days, I might weed through logs, etc. My guess was that caching was involved in some way. In short, my situation is a product of how Windows Installer is supposed to work.

You are correct in that my idea is to have app startup complete any needed configuration. It is a good thought about configurations in version specific folders. I'll be sure to check with Dev to see if they feel that would be a safer way to go. In saying that, I don't know that the items I have slated for change will require this, but I will certainly check with them.

Thanks all SOOO much!!!
Answered 12/02/2011 by: Superfreak3
Black Belt

Please log in to comment
0
When User1 installed the app, [PersonalFolder] evaluated to User1's Documents folder, and that's what's cached when the installation is complete. Cached where?!? The user won't have rights to alter the MSI or the installation metadata in the registry, so...?
Answered 12/04/2011 by: VBScab
Red Belt

Please log in to comment
Answer this question or Comment on this question for clarity