Software updates and UAC - windows

How does Windows handle security and software updates? I need to deploy software to several computers, which will be regularly updated. The update just downloads and runs the new installer. Obviously for the initial installation an administrator needs to run the installer, but after that is the installer white-listed to be run as a non-administrator? This is for XP and 7. The installer is an msi generated with WiX.

No, the installer is not white listed. Even if it were, the update is another installer. So the answer to your question: users will have to confirm elevation in UAC prompt.
Firefox and Opera are the examples. Every time an update is ready to be installed, the updater shows UAC prompt. Chrome on the other hand updates without UAC prompt, simply because it installs into user's profile which is not write-protected (I mean current user has full rights).
Firefox plans to implement a service to facilitate the update process. The service runs under system privileges, it can start the updater with system privileges without user consent for elevation, because it already has full access to the system. This is how antivirus software updates itself. Usually there are two processes: the service and the client which displays UI and communicates to the service.
In the case of MSI, there are system policies. For example, you can enable a policy according to which any Windows Installer-based installation will be run elevated. Usually patches (minor updates) are run elevated. There may exist a policy which controls major updates (where the old version is uninstalled and then a new one is installed), yet I am not aware of such.

I don't know WiX, but it is possible to generate an .msp patch for your existing installer package. If the MSI is properly filled out with an MsiPatchCertificate table, you can avoid elevation when patching.
More details here at MSDN: User Account Control (UAC) Patching, Patching Game Software in Windows XP, Windows Vista, and Windows 7

Related

How to automatically update an application installed with Inno Setup

I have an executable application setup.exe for Windows that I realized with Launch4j/Inno Setup based on Java.
I often frequently release new versions and bug fixes.
I would like to know if there is a mechanism to install updates automatically?
Inno Setup does not have any built-in mechanism for implementing automatic updates.
You need to implement that yourself:
Make your application check for new versions (against your application webpage?). E.g. on startup (on a background thread?)
If the application detects a new version, make it download an installer to a temporary location.
Make the application execute the downloaded installer. You can make the installer run in silent mode (/silent switch). The application should close itself, to unlock any files it is using, to allow files update.
This approach will need the update installer to prompt for Administrator privileges. If you need the update to proceed completely seamlessly, you will have to implement a service. For that, see Deploying application with .NET framework without admin privileges.

Is it InstallShield Express 4 or Windows 7 causing me issues when I install a VB6 application

I'm using a very old version of InstallShield Express 4 to package my VB6 application. Installing it on XP, it works great. But when I install it on a Windows 7 box, not using the "run as administrator", everything seems to be read-only. I can't edit an INI file because access is denied. The application just doesn't function properly. It's almost like it can't even access the folder. And it's installed in the default "program files" folder. I uninstall the application, reinstall using the "run as administrator" option, set compatibility of the short cut to "run as administrator", and everything works fine.
My question is this something inherited in VB6 where the application has to run as administrator or is it an InstallShield issue? And if it is an InstallShield Express issue, would the latest version of InstallSheild Express 2012 fix this? I would prefer the user not have to worry about installing or running the application as an administrator.
Nothing is specifically wrong with your VB6 application. I would say it's the older version of InstallSheild which might be the problem in this case.
The feature is called User Access Control (UAC) that has been introduced in Windows Vista and the following Microsoft operating systems to prevent arbitrarily write access into %ProgramFiles% by applications. You can still perform it manually (by copying and pasting files into %ProgramFiles%) but UAC will prompt for your permission.
To make sure your application behaves expectedly, save application settings in %APPDATA% or in registry, NOT in %ProgramFiles% directory. During installation or uninstallation of your program which requires write access into %ProgramFiles%, you'll have to run it as administrator (unless of course you have UAC disabled which is a massive security risk and strongly recommended against).
Yes, there is something specifically wrong with your VB6 app. It is storing its data in the wrong place. Your application cannot access the program files folder, unless it is running as administrator. This is due to User Account Control, as explained in gsabil's answer.
Here are some solutions (the best one last)
Always run the VB6 app as administrator.
Turn User Account Control off. This opens some security holes and is not recommended
Make your install program change the permissions on your installation directory, granting write access for all users. This is rather a hack, but it could be a fast way to get your program working
Change your application (not your install program) so that it stores its data in %AppData% rather than in the installation directory. This is preferable. Here is some detailed advice on how to do this in VB6

visual studio 2005 setup project from xp to windows 7

I've been developing in VS 2005 on an XP machine for the past 3 years. We're now getting new PCs with Windows 7. What I've noticed is my setup projects require admin rights to run. This is a problem for me because no users (including me) have admin rights, only helpdesk support staff.
I'd like to run my Windows installer setup projects without admin rights- is that possible?
Also, I'd like to continue to create installer files that users without admin rights can run. Is that possible, or will all my setups now need to be installed by someone with admin rights?
I've looked into ClickOnce deployment, but I don't have a web server available for installations.
Also, I've looked into digital certificates, but I have no budget. Is there a way to get a certificate for free? All my applications are for internal use, and I understand these security issues are for web applications.
Is free deployment of internal applications no longer supported?
Thanks for your input,
-Beth
It is possible to run Windows Installer setup without admin rights. Look at Single Package Authoring article for an overview how to create a package that support that. You can also prepare a package that will run only in non-admin mode. Note however, you will not be able to write to Program Files and other system-protected areas when installer runs in non-admin mode.
You can use self-signed certificate to add digital signature to whatever you want. The only thing is that this certificate will not be trusted by default. However, it's not issue when used internally: it can be installed as trusted on machines where it's required. See makecert.exe and signcode.exe tools.

How can I make my application install scripts to bypass User Account Control in Server 2008?

I've written a bunch of VBScripts to install software (like SQL Server Express, WSUS etc.) on my Server 2003 boxes which has all been fine. I'm now adapting them to new Server 2008 boxes and they now won't run without bringing up the UAC prompt.
I know this is normal behavior, but is there any way I can disable UAC, run my install string and then enable UAC again?
Technet on UAC in Server 2008, in short use secpol.msc or gpedit.msc; you probably want to silently elevate ("No Prompt" is the actual value, the setting name itself varies depending on whether you're running as an administrator or a standard user) rather than disable UAC altogether. Disabling UAC turns off a number of other features, most notably some virtualization, which could break some of the programs you install down the line.

Why does Vista not allow creation of shortcuts to "Programs" on a NonAdmin account? Not supposed to install apps from NonAdmin account?

I'm working on an installer (using Wise Installer, older version from like 1999).
I'm creating a shortcut in the Programs group to an EXE. I'm also creating a shortcut on the Desktop.
If the install is run from an Admin account, then I create the shortcut on the Common Desktop and Common Program Group (i.e., read from the HKEY_LOCAL_MACHINE\Explorer\Shellfor All Users).
If it's installed from a NonAdmin account, then I install to the HKEY_CURRENT_USER's desktop and Program Group.
Behavior
Install on:
XP NonAdmin - Desktop and Program Shortcuts install OK.
Vista Admin - Desktop & Program Shortcuts install OK.
Vista Non-Admin, UAC off- Desktop shortcut installs, but Program Shortcut does not. However, the Program group folder they're supposed to be installed to does get created.
At the end of the install, I launch the Program Group that has the shorcut. It launches in all of the above. I can manually drag a shortcut into that folder and it works just fine.
I'm bloody baffled.
I've tried installing some other commercial apps (Opera, Foxit, FireFox) Only FireFox will install under NonAdmin (and only if you select something other than Program Files, which I was aware is off limits to nonAdmin acounts). And FF doesn't install an Uninstall Icon nor
Uninstall support from the Remove Programs.
I tried installing IE 7 and it requires Admin to install. It won't even install with temporarily elevated Admin.
Perhaps the idea is that you're not supposed to install software in Vista from a NonAdmin account?
Vista does some nifty transparent redirection to provide backwards compatibility with non-vista applications. Try installing to the All Users location as a non-admin, and Vista should transparently put your shortcuts somewhere unique to that user.
I had a permissions issue with an installer I created when users started installing on Vista. What solved my problem was renaming the installer to install.exe (or setup.exe).
-Dave

Resources