Application Requirements and how they translate to installation requirements.
Hi all,
For years our company struggled with a per user-per machine install and application marriage. If used to be that the install and the app accessed 'stuff' in both machine and user locations. Accessing the user locations caused repair installs to occur when non-installing users would attempt to use the software. This was not seen as favorable by end users as it basically freaked them out.
So, through the years we've whittled away at the install to make it strictly a per machine process, which as we all know required Admin rights for installation. This is now seen as unfavorable for deployment. I know we have a choice, either per machine or per user and the two really shouldn't be mixed. I also know that with recent versions of Windows Installer we can create dual role packages that, buy utilizing ALLUSERS/MSIINSTALLPERUSER properties, can handle file redirection, etc.
I guess I'll start investigating that option, but I would like to know what should the requirements be for the actual application. I would like to be able to present our development teams some best practices to follow if there desire is per user. Should the app not write to HKLM or protected file system areas at runtime? Should I just ignore the functionality of the app and deal with the install only in handling placement to user area or should the app simply fall in line with application requirements.
I'm not sure if makes sense to have a per user capable install for an app that may require elevation.
If anyone can help forge a path and determine which is the best starting point that would be great!!
For years our company struggled with a per user-per machine install and application marriage. If used to be that the install and the app accessed 'stuff' in both machine and user locations. Accessing the user locations caused repair installs to occur when non-installing users would attempt to use the software. This was not seen as favorable by end users as it basically freaked them out.
So, through the years we've whittled away at the install to make it strictly a per machine process, which as we all know required Admin rights for installation. This is now seen as unfavorable for deployment. I know we have a choice, either per machine or per user and the two really shouldn't be mixed. I also know that with recent versions of Windows Installer we can create dual role packages that, buy utilizing ALLUSERS/MSIINSTALLPERUSER properties, can handle file redirection, etc.
I guess I'll start investigating that option, but I would like to know what should the requirements be for the actual application. I would like to be able to present our development teams some best practices to follow if there desire is per user. Should the app not write to HKLM or protected file system areas at runtime? Should I just ignore the functionality of the app and deal with the install only in handling placement to user area or should the app simply fall in line with application requirements.
I'm not sure if makes sense to have a per user capable install for an app that may require elevation.
If anyone can help forge a path and determine which is the best starting point that would be great!!
0 Comments
[ + ] Show comments
Answers (2)
Please log in to answer
Posted by:
Badger
9 years ago
Why does an MSI repair freak your users out??
If its causing that much grief, for Apps that have user information, you could try doing an ActiveSetup to force a silent repair so they wouldn't see it.
If its a per user install, it cant do anything in machine areas. Not just for runtime, it would still need admin rights to install to the machine locations.
You basically have to write 'portable apps', so you can pick the app up and run it anywhere. This might work, depending on your apps, but a lot of windows apps need things that are in the shared locations, like Windows, System32 etc. Portable apps could still read from there, but they would not be able to copy files to there if needed.
You would then end up with your developers writing their apps to have copies of the (unregistered) files in a separate location when it 'installs' to the user location, either AppData, or the user based ProgramFiles.
You also need to really consider the amount and size of the apps and the impact this approach will have on user profiles especially if you are heavily committed to VDI.
Comments:
-
I have no idea why it freaked them out. I think our Helpdesk would describe this to the users as self repair in the context of Windows Installer. I think the 'repair' part of the explanation instilled a sense of app 'broken-ness' in our Clients. Although it is/was normal Windows Installer behavior, they saw it as something in constant need of repair.
I explained to my dev co-workers that the install can place files wherever they would like. I can make the install per user and force the 'stuff' to the user profile, but I need to be sure the application will still work properly. I guess it would be nice to find a do's and don'ts of app development for UAC.
I think there is an additional roadblock in that we integrate with some third party products, which require some of our information in HKLM without redirection to the user area - if we can't circumvent that, I think all bets are off and we have to require Admin rights at install time.
If it were up to me, I'd live with Admin requirement to install. The problem with us, as a software provider, we are also mired in deploying at end user sites. - Superfreak3 9 years ago-
WindowsXP is not in play here is it?? Don't worry too much about UAC, for the last 20 years they should have been writing app to run as a user, UAC just forces that now (Finally!!). Your biggest problem would be hard coded stuff. Try not think more of programmatic stuff (API). Also how do you deploy your software?? That could be your next problem if you go down the per user route, it will have to be deployed for every user on the device, no more, 'the software is on the machine, just run the shortcut'. You also have to deploy it per user too. - Badger 9 years ago
-
Yes we still have customers that use XP, believe it or not.
I understand the per user deployment concept. We have a widget that looks at .ini values on the Server and compares to the current version on the workstation. If Server>Workstation, and update/upgrade is deployed. This will happen when the user logs onto their machine (or from a shortcut) so all users that have installed the software would be covered.
Typically, from what I'm told, we don't have many instances where more than one windows user uses our software so that shouldn't be a big deal. If more than one win user has to install the machine, so be it. Updating shouldn't be an issue.
I just want to be sure there are no special concepts the development team should be following. They never really took the time to investigate UAC thoroughly, ins and outs of new OSs, etc. - Superfreak3 9 years ago -
Since you say XP, the big problem with writing per user MSI installs for XP, was that there was no per user ProgramFiles. Vista and above have a per user ProgramFiles. So you will need to have your apps re written to be either fully portable (copy the folder anywhere) or to run from %AppData%. Which is basically the same as fully portable. But you wont be able to use any ProgramFile variables. - Badger 9 years ago
Posted by:
anonymous_9363
9 years ago
As m' learned friend says, just use Active Setup. Used with '/qn', your users will have no idea that self-healing is happening.
You might also want to educate your Helpdesk personnel to stop using the term "repair" and use "tailoring to your unique requirement" in its place. The statement is true and the language makes the user feel that they're getting special treatment. I'll bet most will end up apologising for calling.
You might also want to educate your Helpdesk personnel to stop using the term "repair" and use "tailoring to your unique requirement" in its place. The statement is true and the language makes the user feel that they're getting special treatment. I'll bet most will end up apologising for calling.
Comments:
-
Ha, I've been trying to educate HD for years. Not to digress, but way back, before I arrived at the company, they had a widget they would run after install to register everything. Through the years I've been telling them that registration is taken care of during our actual install processes. I'd say this has been going on for 6-8 years! The other day I overhear HD telling a customer to run this archaic post install registration process. It makes my blood pressure shoot through the roof. You would think that one of them would question why this hokey step still has to be done. Nope, they just keep on chugging with it. I would think end users would ask the same thing. It sometimes seems like I'm in the Windows 3.1 days.
Anyway, I'm not too concerned about the repair install stuff. We're more concerned about moving to an install that doesn't require Admin rights. I know to stay away from restricted areas of the files system, HKLM in the registry, Common App Data (so one user's removal won't rip out something used by others), etc.
I just want to be sure that after changing all that, the app still works and won't require Admin stuff as well. - Superfreak3 9 years ago
