I have published two programs to users through active directory. This first allows non-administrative users to install with no problems. The second, Flash Player's latest version, fails for non-administrators.
The user exists in the OU and the group policy is enabled. The .MSI file rests on a shared network drive that everyone has access to.
Is there another location to set permissions for published msi installers?
MSI packages don't use permissions for the installation process. It all depends on their configuration.
It seems that the Flash Player MSI uses a per-machine installation, so non-Administrators cannot install it. Also, this cannot be changed without converting normal user accounts into Administrators.
A solution is to deploy it only to Administrator users.
Related
My installer run in all users, and it saves user information in the AppData folder.
The problem is that, when the installation is finished, an executable is launched by means of an Exec and it is launched as the administrator user, so all the session data is stored in the administrator's AppData. I want to run the installation as Admin but the last step as the current user.
RequestExecutionLevel admin
Can I launch my application as the current user? Can I keep the current user before ask for admin privilages?
The Microsoft guidelines say:
Certification requirements for Windows Desktop Apps
Apps must install to the correct folders by default
10.6 Your app must write user data at first run and not during the installation in per-machine installations. When the app is installed, there is no correct user location in which to store data.
If you have some sort of default user data/template you should install that in %ProgramFiles% or %ProgramData% and your application should copy that data to %AppData% the first time a user runs your application.
The ShellExecAsUser and StdUtils plug-ins can be used to execute your application as the "real" user on the finish page.
The UAC plug-in allows you to access the "real" users %AppData% and registry but I don't recommend this approach because the plug-in is hard to use and it really promotes incorrect behavior. You are very likely to end up with a install pattern that only works for the initial user and not other users on the same machine.
We are writing an installer for our Windows tool. As our tool uses an updater (wyUpdate) and we want that users WITHOUT Administator rights can performs updates. Which is the right directory to install the app to? The standard C:\Program Files requires Administrator rights, so we have discarded this option. After reading a bit on the Web, we have chosen AppData, i.e. C:\Users\USERNAME\AppData\Local.
Is this best practice? Or should we use another directory?
If you do not want to allow your users to mess with the installed program, you have to install it to a folder that needs Administrator privileges.
To allow an automatic update of such application, you need to develop/install a service that runs with Administrator privileges, which will update the installation. This is what Windows Update, Mozilla Maintenance Service, Google Chrome Elevation Service, Adobe Acrobat Update Service and similar services do.
If you do not want to implement a service, but you want the application to be used by all users of the machine, you need to install it to a folder that can be accessed by all users, yet does not need Administrator privileges. You can for example use C:\Users\Public. See also Is there a shared folder in Windows to which non-elevated users have write access?. You can use PUBLIC environment variable to resolve that path.
If the application is to be used by one user only, then you are ok with using C:\Users\Username\AppData\Local – {userappdata} in Inno Setup.
Related question: Deploying application with .NET framework without admin privileges
A customer installing my companies software package has no problem installing the package silently when running as an admin account. The software and the service both install correctly and start up post installation. However - they need to push this application to all the computers in a particular group.
They are using SCCM (I do not know the version) and the software package is a InstallShield .exe packaged .msi.
When they try to use the NT Authority\System user to push the package to their test device, the installation fails soon after the 3rd party software package that is included completes. The error log displays that it is a SDDL error 1943. Any idea why this would occur on the NTA\System account and not on a local admin account for a given machine?
The silent install string we are using is setup.exe /s /v" /qn AgreeToLicense=Yes SetupType=Typical"
I'm not a dev, so I dont have direct access to any code in the software, simply a tier 3 tech support working with customers.
Sounds like your MSI is using the MsiLockPermissionsEx table to specify an SDDL string on some resource its installing or configuring (either file, directory, service or registry entry). Either the SDDL string is misconfigured (unlikely if it works from one account but not another) or the ACL on the target directory/service/registry key have become corrupted, which isn't completely unheard of.
You could try getting the customer to deploy a domain account as local admin to the computers and then set SCCM to run the package with this account. I wouldn't recommend this though as it carries inherent security risks of its own.
I'm afraid this may be one that your developers (or whoever created the MSI) need to work out with the customers to find out which resources are at fault and progress the diagnosis.
Sorry I couldn't be of further help.
I think I have found the issue. During install the .msi writes a file to the desktop to be read for configuration settings for the service as being installed. I had the file (and I am sure the customer did as well) already written to the desktop when I tried to invoke the System User for install. This does seem to be an ACL issue, in reference to the System User read/writing to a local user desktop. When the file was deleted, I received error 1406, that it could not write the value of a key. Looking on the desktop, the file had also never been written to the local desktop. When the file was already there (as such with a previous install) I get the error in the original post. At this point I am moving forward testing this as an ACL error and notifying the devs of my findings.
One of our applications is VB6 app, which requires Tabctl32.ocx.
So I added "tabctl32.msm" (which contained it with the version 6.1.97.82) to per-machine based Wix. When I ran this per-machine MSI, it installed that OCX and the application worked fine when I as an admin logged in and launched the VB app.
However, if any person with a standard user privileges logged in and launched this VB app for the first time, it triggered an MSI self-repair. Once the self-repair completed for that user, it worked and didn't trigger the self-repair any more for that user. This self-repair didn't occur for the admin users.
When I examined the MSI with Orca, in "ModuleDependency" table, this tabctl32 module had the dependencies with COMCAT msm and OLEAUT32 msm, we installed them with the merge modules as well.
I don't understand why the self-repair doesn't happen for the admin-users but for the standard users?
Can anyone explain what's going on here?
It may be nothing to do with standard users or admin users or OCXs - it may just be different users.
If there is any resource in the MSI that is owned by a particular user (such as a user-oriented file in Personal folders or others, or registry entry in HKCU) then the first install will install all of these for the installing user.
If another user logs in and uses the app (installed per machine, hopefully) then repair triggers (such as using a shortcut) will notice that these user items are missing for this particular user and will install them. This should happen only once - it the repair happens repeatedly for the same user then it's something more serious.
In any case, the application event log should have an MsiInstaller log entry with some data about the product and the missing component.
This may also depend on the VB6 app - it's old, has no manifest, and so may be interacting with UAC in strange ways. For example, if its behavior is virtualized to use a \VirtualStore location for the system folder then it may well need to reinstall the tab control into that virtualized system folder. Admin users wouldn't have the same issue.
I'm currently working on my applications installer and I'm wondering where the executable files should be installed to in Windows 7.
If I'm installing as admin my executables files get put in C:\Program Files.
If I install my product as a normal user where should the executables be put?
Thanks in advance.
Which installer are you using?
MSI runs in elevated privileges. You can install your application in program files folder
Put the files in the user folder.
This will mean that the application is only available to that user.
You should probably store that in the AppData directry, as I saw you mention in reply to #ChrisF. Remember that the user can move this directory though, so I wouldn't point to it explicitly. There is an environment variable that you can grab, that only applies to the logged-in user, which is %AppData%.
Keep in mind that putting it in %AppData%/Roaming would follow the user across multiple machines on the same Domain and %AppData%/Local would just stay on the one machine.
The executables should be under Program Files, who's precise location may vary from installation to installation. This means that the setup should run elevated. If InnoSetup makes .msi files, they will request elevation. If it makes a file called setup.exe, it will also request elevation. If for some reason the exe has a different name, like GetStarted.exe, then you should hand create an external manifest (GetStarted.exe.manifest) and put in requireAdministrator for the requestedExecutionLevel which will ensure your installer requests elevation.
Regardless of how it requests elevation, if the user doing the install is an admin (eg you) they will just have to click consent. If they are not an admin they will need to get an admin to consent for them. After that the installer will be able to write to Program Files.
If it's important to you that non admins be able to install the app then have the executables go under the users profile - but that would not be my first choice. The protection given to Program Files means that users are less likely to find themselves with messed up copies of your application if you install it to the protected area.