I have a puzzling situation with the Inno Setup FileExists function.
Here's the situation. I have three networked computers with like WORKGROUP names.
1) Windows 7 32-bit
2) Windows 7 64-bit
3) Window XP Service Pack 3
1) and 3) have been setup as servers with read-write shares, ex. ShareExe and ShareData
The problematic Inno Setup creates shortcuts to the executable in the ShareExe folder. It asks the user for the ComputerName of the server and then uses FileExists to verify correct input.
Running this setup on the XP (3) machine and specifying 1)'s computername works just fine, however when running the setup on the Win7 64-bit PC and specifying the same ComputerName as with XP, causes the FileExtsts test to fail.
Strangely, I can go to Network Places and open the ShareExe folder and successfully run the executable. My question is, "why does Inno FileExists fail only on the Win 7 64-bit machine?" I cannot find anything in the reference materials that suggest any version differences with FileExists. (I also tried FileSearch with the same results).
TIA
In Windows 7 (and Vista) with UAC enabled, by default network credentials and drive mappings are not shared between admin and non-admin contexts, even for the same user.
By default, Inno elevates to admin permissions (via PrivilegesRequired=admin), since most installations must (and should) be performed per-machine by an admin user. However this means that any credentials prompted for or saved by Explorer when browsing for the desktop are not available to it.
When files are accessed directly by APIs (as with FileExists), Windows will typically try to silently connect to the server using the same username/password as was used to log into the PC; if this fails then it just reports an error since it has no way to prompt for alternate credentials at that point. So if you can ensure that the login details on both PCs are the same, then it should work. (You usually get this for free on computers connected to a domain, but not a workgroup.)
If that isn't possible, then something else you could try would be to force the access via a shell dialog -- if the FileExists fails, then use GetOpenFileName to prompt the user to find a specific file in that folder, using the same initial path. I haven't tested this, but I think this should result in Windows displaying a credential prompt and then you should be ok after that.
(If this is for an internal app, then another option is to disable the separation of credentials [via a security policy setting] or UAC entirely, though the latter isn't really a good idea. Of course this isn't tolerable for a general-release app, and it's cleaner if you solve it one of the other ways anyway.)
Related
I have created a small vb6 application which edits the registry in HKLM hive. It makes use of function RegSetValueEx. But when run the exe file in windows 7 and windows 8 pc it does not edit the registry even if run it in administrator user.
In windows XP it works fine.If i run same application as "run as administrator"(by right clicking exe and then run as) in windows 7 and 8 then it works properly.I think the windows 7 and 8 id designed to work like this only. But is there any method i can edit it without running as administrator? Or is there any code in vb6 which does the same.
Here is my small code
Important:
When checking the code create exe and then run the exe and click on button(HKEY_LOCAL_MACHINE\SOFTWARE\Demo registry gets added in wow32 node because vb6 is a 32 bit appliaction).Running the code directly by opening code allows the registry to change.But creating the exe and then running it gives the problem which is the real time scenario in any application.
Microsoft has been warning developers since Windows 2000 that access to the HKLM branch of the registry should not be performed as normal user, as it will sooner or later be restricted to administrators. They also said you should not write to Program Files.
They didn't enforce that rule until Windows Vista, so nobody felt the need to change anything.
Now you have it: don't write to HKLM as normal user - it doesn't work. Don't write your settings to Program Files. It doesn't work.
Application run by the normal user may write their data to user folders and user hives in the registry, nowhere else.
If your application's sole purpose is to write to that value in the HKLM hive then you will need to add a "requiresAdministrator` manifest to the executable, causing Windows to prompt the user for admin access every time it's run.
If this is a small part of a larger project, then you should use COM elevation or just run a small stub executable with the manifest above, allowing windows to only prompt when it's required.
If your application doesn't require admin access at all then you should stop it trying to write to admin restricted locations, and instead use the user's own HKCU hive.
I have a network file share with a number of shortcuts in it, each of which runs one of several applications which load data into them from that particular file share. The network file share & applications are located on a system running Server 2003, and all permissions on that file share have been unchanged.
The applications run fine when executed from a system running Windows XP. One system was just changed to Windows 7. In running the applications on Windows 7, the user was (then) a local administrator on that Windows 7 system. Initially, they each functioned properly, and I was able to print from one particular application. However, when the user is now no longer a local administrator on that system, the application will not print, saying it requires local admin permissions to do so. You can get around it by right-clicking and running with elevated permissions on the shortcut - the application will print & function fine.
However, remembering to right-click & run with elevated privileges is not easily remembered, especially when you've navigated down several levels in the application only to find you're unable to print from within the application.
The shortcuts are located either by using UNC names or by mapped drives (depending on the user). In my test, I'm using the UNC name -
\\servername\datafolder\content\myshortcut.lnk
If I go to Properties on the shortcut, the Compatibility Mode is greyed out and cannot be changed. However, if I go to the Troubleshoot Compatibility & accept the recommended settings - the application executes fine. However, when it tries to save the changes the Troubleshooter recommends, it says that the application is incompatible. (FWIW, the Fix Application sets CompatMode = #WINXPSP2 and UserVerifySolution = Verify_YES).
Short of:
Remembering to run the shortcut with elevated permissions, OR
Making the user an admin on the local system
is there a way to apply changes in compatibility mode across a number of shortcuts on a network share without making more of a mess, or opening these shortcuts with elevated privileges?
Thanks,
SC
I'm marking this as a community wiki because I'm not really looking for one complete answer. So if you feel like posting one or two things that will activate the UAC prompt instead of a comprehensive list then go ahead.
What actions in Windows will activate UAC? I'd like to avoid it as much as possible because my application doesn't need admin privileges. And I'm sure many other people want to avoid it.
Specifically, I would like to know if reading from the registry would activate it. Or writing to it?
You don't need to address the above question, just anything that will activate it is fair game.
It's really hard to Google anything about UAC because you get bombarded with articles about how to disable it. And I'd rather not have my application make the assumption UAC is disabled.
Nothing "activates" UAC.
If your application would fail to run as a standard user under Windows XP it will fail to run under Windows Vista or Windows 7 as a standard user.
What you are really asking is: what actions can a standard user not perform under Windows?
The things a standard user cannot do are pretty well known (they've been the same since Windows 2000). The main ones are:
modify anything in HKEY_LOCAL_MACHINE
modify anything in the Windows directory
modify anything in the Program Files folder
If you try to do any of those they will fail on:
Windows 2000
Windows XP
Windows Vista
Windows 7
Nobody should have been running as an administrator for day-to-day computer use. If your application did any of those bad things in Windows XP it would fail. The user would have to:
logon (or fast user switch) to an administrator
perform the administrative task
switch back to their real account
UAC is a convience mechanism, allowing you to easily temporarily switch to an administrator. Nothing you do will "trigger" it; you have to make it happen.
If you know your code needs to modify a file in C:\Program Files\My App\Data, then you should add a button on your form that will trigger the elevation.
You then need to launch an (elevated) copy of your program, do the thing, and close.
I created a launch4j installer (an exe-wrapper for java programs) and named it "MyApp.exe". It doesn't need any admin authentication. It just runs fine without any UAC prompt.
BUT: If I rename this installer to "install.exe" or "setup.exe", the UAC icon appears and I get a UAC promp when starting the installer.
Seems as if there are some "reserved words" in filenames that cause windows to start a program with elevated rights (UAC).
My application consists of two parts: A Windows Service running under the LocalSystem account and a client process running under the currently logged in regular user.
I need to deploy the application across Windows versions from XP up to Win7.
The client will retrieve files from the web and collect user data from the user.
The service will construct files and data of it's own which the client needs to read.
I'm trying to figure out the best place (registry or filesystem, or mix) to store all this. One file the client or service needs to be able to retrieve from the net is an update_patch executable which needs to run whenever an upgrade is available.
I need to be sure the initial installer SETUP.EXE, and also the update_patch can figure out this ideal location and set a RegKey to be read later by both client and server telling them the magic location (The SETUP.EXE will run with elevated privileges since it needs to install the service)
On my Win7 test system the service %APPDATA% points to:
C:\Windows\system32\config\systemprofile\AppData\Roaming
and the %APPDATA% of the client points to:
C:\Users\(username)\AppData\Roaming
Interestingly Google Chrome stores everything (App and Data) in
C:\Users\(username)\AppData\Local\Google\Chrome
Chrome runs pretty much in exactly the way I want my suite to run (able to silently update itself in the background)
What I'm trying to avoid is nasty popups warning the user that the app wants to modify the system, and I want to avoid problems when VirtualStore doesn't exist because the user is running XP/2000/2003 or has UAC turned off.
My target audience are non-tech-savvy general Windows users.
Chrome doesn't have any services running under the LocalSystem account, though.
If you want to have files that can be shared between accounts on the same system, store them under the %ALLUSERSPROFILE% folder.
If you just want to be able to auto-update programs, then doing what Chrome does is fine: just make sure you launch the updated elevated when UAC is turned on.
I wonder if it's possible to programmaticaly share folders in Windows 7 while running in restricted logon session:
1) NetShareAdd returns ERROR_ACCESS_DENIED.
2) Command line net share says the same.
3) But explorer has no problems creating new shares without invoking UAC. How does it do that?
Any help will be greatly appreciated.
UAC in windows 7 is less strict than it was in Vista. Windows 7 regards Explorer as a trusted application so it will silently create the share without a UAC prompt (you can change this behavior in the Control Panel).
Your application isn't a trusted one (OK, you trust it, but the operating system does not). Probably you also don't explicitly demand administrator rights in your application. In that case Windows 7 treats your program as unprivileged and refuses access, that why the error message.
A solution could be adding a manifest to your program requesting an ExecutingLevel of requireAdministratior. See for example Demand UAC elevation for an application by adding a manifest. But then your whole application runs as administrator. There are some more granular solutions.