Need install at user level, but elevate as needed

cpp1977
1st February 2012 19:59 UTC

Need install at user level, but elevate as needed
For the install I'm building, I'm needing to read keys in the registry placed there by another one of our installs. This must happen at a user level, because if the install is elevated to admin, those keys don't exist. But then, I need to add files to Program Files (x86), and it's failing simply saying "error opening file for writing:.... etc"

Most of what I need to do happens at user level, but for things like installing files I want it to up the level momentarily to get the files down. We have a wix install that does something like this. Can NSIS do it?

thank you.

Brummelchen
1st February 2012 20:37 UTC

IMO you cant elevate in between.

those keys don't exist

provide some code please, admin level just elevate only rights, not the place!

cpp1977
1st February 2012 23:19 UTC

I'm home now and not in front of my work pc, but the kind of code I'm doing is like this:
(I may mess up syntax as I'm pulling from memory, but the logic is the point here)


; this next line has to be at "user level"
ReadRegStr $0 HKLM "\software\mycompany\otherstuff\filelocations" "installlocation"

SetOutDir $0
; This next line must be as admin because $0 contains a folder located at c:\program files (x86)\etc\etc
File myfile.exe

MSG
2nd February 2012 06:56 UTC

Originally posted by Brummelchen
admin level just elevate only rights, not the place!

No. The entire HKCU hive is user-specific. That's the whole point.

cpp1977: You can use enumusersreg to enumerate all userhives in HKU.

Brummelchen
2nd February 2012 13:56 UTC

The entire HKCU hive is user-specific

thats right - but elevating does not mean changing user - user just gain this moment admin rights.

ReadRegStr $0 HKLM

HKLM is branch for system, not user (HKCU), and is for all user same!

script needs to elevate for writing in programfiles.

but as i see (x86) - user uses the wrong branch in its 64bit system.
it need to set setregview to 32 or 64 to get the 32bit or 64bit registry tree
so there is no wonder why i always catch no value

see also
http://forums.winamp.com/showthread....=1#post2841243

nsis is a formerly 32bit program so it access is not this branch
HKLM "\software\mycompany\otherstuff\filelocations"

it access is at HKLM "\software\wow3264node\mycompany\otherstuff\filelocations"
thats the relocation for 32bit programs registry.

read my linked answer!

cpp1977
2nd February 2012 14:15 UTC

Ok, so when I
RequestExecutionLevel admin
If I do SetRegView 32 before my read to HKLM, that works, but now I have a new problem
I need to read a registry key from HKCU, but at admin level, this doesn't exist.
This "enumusersreg" key doesn't exist in NSIS help.
How do I run at admin level, but read the current user's registry?

cpp1977
2nd February 2012 14:19 UTC

Sorry if this posts twice, but the first time doesn't appear to take...

After taking the above posts into consideration, I've gotten a little further, but now I need to read a key from HKCU, but the problem is, if I'm elevated to Admin, the keys I need don't exist.
The enumusersreg doesn't exist in help, so I don't know how to use that.
How can I be in admin level, but read keys from the specific current user?

Brummelchen
2nd February 2012 14:40 UTC

the keys I need don't exist.

then in fact they dont exist

How can I be in admin level, but read keys from the specific current user?

thats not possible without changing to specific user root in registry.

or do you try to install from admin account (different logon) in a users place?

I need to read a registry key from HKCU, but at admin level

there is no difference!

Afrow UK
2nd February 2012 16:03 UTC

Originally posted by Brummelchen
thats right - but elevating does not mean changing user - user just gain this moment admin rights.

Actually, yes it does. If you elevate to an administrator user, you are running as that user. HKCU and APPDATA etc. no longer point to the original user's registry/files. For the registry if you need to write to HKCU for all user accounts, you can use EnumUsersReg (Google it).

Stu

cpp1977
2nd February 2012 16:09 UTC

No, I don't need to write to all users's registry branches, I need to read data from the one that actually ran the install in the first place.

Afrow UK
2nd February 2012 16:10 UTC

You will need to use the UAC plug-in for this; read the registry before doing the elevation.

Stu

Brummelchen
2nd February 2012 17:25 UTC

i will check that out soon Afrow - but strange combo anyway with user registry but program files.

Brummelchen
2nd February 2012 23:42 UTC

Originally posted by Brummelchen
HKLM "\software\wow3264node\mycompany\otherstuff\filelocations"

typo - its: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node

-> HKLM "SOFTWARE\Wow6432Node\mycompany\otherstuff\filelocations"

cpp1977
3rd February 2012 12:28 UTC

This plug in is a bit confusing. So it actually runs a 2nd copy? How do I separate what I want done at user level and pass that into the inner admin copy to have the right data. Initally I thought by running this addon I could just elivate the current install, but I'm guessing that just can't be done. The samples don't quite cover what I need.

Yathosho
3rd February 2012 13:37 UTC

once elevated with UAC, you can call a function using the UAC_AsUser_Call macro. everything in that function will be executed on user level.

i've used this to create shortcuts for a user, not the admin executing the installer. the code in comments is the syntax for older uac versions.

# GetFunctionAddress $0 CreateShortcuts_Startmenu
# UAC::ExecCodeSegment $0
!insertmacro UAC_AsUser_Call Function CreateShortcuts_Startmenu ${UAC_SYNCOUTDIR}

Function CreateShortcuts_Startmenu
  CreateShortCut "$SMPROGRAMS\MyApp Directory\MyApp.lnk" "$INSTDIR\MyApp.exe"
FunctionEnd

Anders
3rd February 2012 14:22 UTC

Using the UAC plugi this way is not ok IMHO, if you install to $programfiles you should create the shortcuts in the all users startmenu... (If a different user runs the uninstaller you will not be able to delete the shortcuts unless they are in the shared startmenu)

Yathosho
3rd February 2012 23:38 UTC

interesting. just wondering what would be an "ok" scenario for UAC_AsUser_Call then?

MSG
4th February 2012 08:00 UTC

The UAC plugin was designed for only one thing: Allowing the Run checkbox at the finish page to execute at userlevel instead of as admin.

Installation should always either be done at userlevel for singleuser (HKCU) or at adminlevel for allusers (HKLM). That's how Windows is designed. Doing it differently is possible, but not proper and prone to problems.

Anders
4th February 2012 08:33 UTC

Originally posted by Yathosho
interesting. just wondering what would be an "ok" scenario for UAC_AsUser_Call then?

Because of different feature requests the AsUser macro was designed to be generic but that does not mean the things you can do with it are a good idea! Any time you break away from the per user or per machine install paradigm you are probably adding bugs (if there are several users on the same machine), the exception is the run checkbox since the install is complete and all you are doing is saving the user from having to start your app from the startmenu. (There can probably be other scenarios, just remember that when a different user starts your application the AsUser action has not taken place)

Originally posted by Yathosho
i've used this to create shortcuts for a user, not the admin executing the installer. the

The correct action here for example is to use SetShellVarContext all and create the shortcuts for all users. In general, if you write to HKLM or $programfiles then you should call "SetShellVarContext all" in .onInit...