Environment Variables and different user profiles

[Sergeant Steve]

Couldn't quite find the right thread for this so stuck it in General and figured it would be moved if need be.

I'm wanting some more information on Environment Variables such as %userprofile%. Lets say software will install to %appdata% which relates to C:\Users\(CurrentUser)\appdata, that's fine, but what if this is a standard user profile and the installer gives a UAC prompt for Admin Privileges which are then provided, surely the software installer is now running in the admin user profile so %appdata% would relate to C:\Users\Admin\appdata?

Or is this not possible because you are still in the (Standard) user account therefore the "Environment" is still technically in the standard user rather than the admin.

 

[Alejandro85]

You're correct in that the path would be deviated when elevating. The "environment" is per-user account, indeed. When elevating though UAC (or by using "run as another user), the launched program will run in the same desktop as everything else (that's why you see it alongside your other programs), but will still be running under different credentials, which means another user account, which means getting its own set of environment variables, security permissions and other things, so it will see the paths for the admin profile, not the standard that launched it.

Within the installer itself, it could be one of two things. The whole process is elevated, so effectively the user will see, within it, the environment of the admin account used to pass UAC, and that will get the buggy behavior you describe. It can also ask for options, folders and everything before elevating, in which case the user will see its own familiar environment, which is in turn passed to the elevated worker process afterwards. Which of those approaches it taken depends entirely on how the installer was made.

The fist behavior I describe is a typical case of a broken installer. Actually, many programs exhibit similar bugs due to assuming that Windows is left at its defaults, and simply fail when those assumptions are not meet (the default being here using an admin account by default and elevation don't requiring an extra password). It's a common flaw of many programs, including some from Microsoft and within Windows itself.

A better option here would be to NOT to ask for elevation at all. Since you want to install to your user profile, you don't require any extra privileges for that, simply copy the files and use (that's the basics of the so-called "portables"). The real reason why installers ask for admin credentials is that they typically deploy to program files, which is read-only for standards, and used system-wide. Your profile is, on the opposite, visible to you only.
I would suggest to use the installer to install to program files, or if you really want to drop it on your profile, use a "portable" version instead.