I have a guy at a company trying to install our program on a user account that they don’t give “admin” privileges to.
I don’t think I have done anything in my app to require admin privs on Windows but when he tries to run the app,
it will not run. Many users are running the app fine without any special privileges.
It gives the following Runtime error that I display in a dialog:
Sub App.Event_open()
Sub Application.
_CallFunctionWithExceptionHandling()
Sub REALbasic._RunFrameworkInitialization()
That is all that it shows. Any ideas or help much appreciated.
I think this has got to do with the UAC security level policy and settings of the company he/she works in. Some companies IT policy do not allow staff to install, some allow but have to get IT to temporary make the staff Windows login as Admin to install then revert back to non-Admin.
Some allow staff to install their non-company approved software. If this is the case, try to install in the user’s AppData location but create a Program folder first to install into. I know some will balk this this suggestion but I remember this is one of the suggestion by Microsoft although I lost the link. Just in case there be any doubt about this, Advanced Installer has this option and it was discussed in their forum.
Whatever way, he/she should consult the IT Dept first.
UAC and GPOs can be a real pita for installing/upgrading apps. The more UAC and GPOs they are installed on the machine the worse it gets for all of us.
By-design non-priviledged Users should not have the rights to install anything or shouldn’t even start a software. And I totally disagree that this is worse. Since NT4 Window has SAFER and GPOs, since Win7 AppLocker. This App Whitelisting techniques in combination with Content-Filtering Firewalls and Anti-Virus helps to protect networks against threats.
It’s more worse that until today admins still do not enforce App Whitelisting and Software Developers still continue to violate Windows Guidelines trying to start helper programs in Appdata folders or trying to save user specific files in common or protected App folders.
Check your App if you’re trying to write something in current WorkingDirectory or App Directory.
User Data belongs to \Users\UserName\AppData\Roaming\ or SpeciaFfolder.Preferences in XOJO
Create proper Software Installers for Windows (e.g. use PrivilegesRequired in your Inno-Setup Scripts)
Sorry I have not been responsive… did not see all these responses.
The App.Open loads some settings info from an external file.
The problem is that the IT guy installs as admin only. Then user runs app. But when user does this they do not have a folder from the installer that is in the appdata support area. That folder is installed to the admin accounts’ app data support area.
I cannot just push this file out from the software bundle if I detect it is not there…just when the app first runs because the external settings flips between 3 different editions of my software that are all in the same codebase. And thus I build 3 installers - one for each edition.
Not sure what to do about it.
Yes this is what I am doing and this is what is causing the problem. The installer installs a file in there in a folder for my application. But since IT admin guy installs under his account UserName is his admin account. Then real User runs the app and that folder is not there under his AppData\Roaming account.
This is why I suggested the IT has to temporary make the user as administrator to install the program. After installation, make the user no longer administrator. Then the user will have all the folders and files in his own space.
When a Windows user is not administrator and install a software and get a prompt for administrator credencial , and the administrator (another person, another Windows user login) provides the administrator credencial, any installation although initiated by the user will then be installed into the administrator’s space.
Can you have the IT guy run an app (as admin) that writes your settings file to local_machine in the registry? The user, even though running as non-admin, should be able to read from local_machine. I do this with corporate registration info for one of my apps, while user-specific registration info goes in the user area of the registry.
If there is a need to write to the registry, should write to current_user. The user has all read and write access to his own current_user registry space. Avoid writing to local_machine which requires administrator privilege. Reading from it can also be a problem in some security settings.
For corporate licensing info, where the installation is per-machine, then yes no choice but to local_machine. But if per-user, write into current_user.
Your solution is simple: Change your installation script or software design. Basically it’s the same in all multi-user enviropments. Windows has certain common folders for users. In Inno Setup these are represented by cf, cf32, cf64, usercf constants.
To promote a user as admin and demote after installation is a common, but very bad habit. If the user’s account is compromised or has any malicious software starting-up within his profile then you give these bad guys a free-ride straight into your enterprise network. Though many admins do this because of non-compatible installers or software. IMHO each app violating these basic Windows rules shouln’t be claimed as Windows-Software anymore. Unfortunately Microsoft never was strict enough to enforce this in their Windows logo and compatibility programs.
So I am sorry to tell you that the Admin is doing his job well. In bigger networks these installations even would be done completly unattended, headless and remote only by scripts without clicking on interactive windows or copying any files around. This is the reason why installers are so needed on Windows platform. Here are only some of the issues a Developer should always keep in mind when delivering windows software:
never use hard-coded references to folders or files due installation process
use system default program folders by default (or let the user decide by his own conviction)
enforce admin priviledges due installation and dont expect to have full rights shortly afterwards
support multiple user logins each with different settings and priviledges on a single mashine
write user specific stuff in the user context (appdata/roaming) folders, always!
do not start any executables outside program folders esp from temp or appdata. A lot of applications try this for helper apps. Unfortunately this is the same what malware does and is blocked by policies.
use installers with commandline and silent installation options
List is not complete, if you would like further information on this, google (or duckduckgo) for Windows logo or compatiility programs.
Since 2014, I have gotten rid of components and things that require admin to install or write. Everything go into user location. I have also do my installer to install per-user since my licenses are to individuals and I do not want them to share with their different shift colleagues using the same computer. I also install into %LocalAppData%\Programs by default (with dialog for user to change to their preferences).
Since then, I do not have a single user coming back with installation problem, whether they work in stock-broking firm, stock-broking arm of banks or fund managers.
Here is the link to Microsoft’s website regarding Windows Installer Installation context. There are 2 columns: left is per-machine and right is per-user. Scroll down about 55 to 60 pct of the page is contxt on ProgramFilesFolder. Notice per-user is %LocalAppData%\Programs.
So there is nothing wrong, as far as Microsoft is concerned, about running codes from AppData per-user, so long as it is from %LocalAppData%\Programs.
And so long as nothing requires admin, the installer and the software can be scripted to . Then no admin prompted will appear, unless the corporate IT config their computers otherwise. Still user should check with their IT regarding company policy.
[quote=318900:@Cho Sing Kum]Since 2014, I have gotten rid of components and things that require admin to install or write. Everything go into user location. I have also do my installer to install per-user since my licenses are to individuals and I do not want them to share with their different shift colleagues using the same computer. I also install into %LocalAppData%\Programs by default (with dialog for user to change to their preferences). Since then, I do not have a single user coming back with installation problem, whether they work in stock-broking firm, stock-broking arm of banks or fund managers.
[/quote]
This doesn’t prove you’re right. You’re lucky that no one of your clients do not have a proper installed and operated enterprise network with enabled AppLocker or App Whitelisting. If so, then your kind of installation wouldn’t work there and you would see something like this:
in english: this operation is blocked by GPO. ask your admin for more information
[quote=318901:@Tomas Jakobs]This doesn’t prove you’re right. You’re lucky that no one of your clients do not have a proper installed and operated enterprise network with enabled AppLocker or App Whitelisting. If so, then your kind of installation wouldn’t work there and you would see something like this:
in english: this operation is blocked by GPO. ask your admin for more information[/quote]
I am not proving I am right or not. I used to have installation problems. I have changed everything to follow Microsoft’s guideline since 2014 and since then I have zero installation problem. Quite a fair number of my users are in financial institutions. I have worked for many years in banks and I know how strict the IT there are. I am happy that I have finally gotten rid of installation problem and just wanted to share my bit of experience.
Again I am not here to prove I am right or not. Just sharing my experience what what is acceptable to Microsoft guideline and try how to avoid installation problem.
Do note I have said this twice already:[quote]Still user should check with their IT regarding company policy.[/quote]
Why not use the system-shared location of C:\ProgramData\YOURAPP\Stuff instead of the user-specific location. That way, any user can access your associated files.
