AppUpdate on non-administrator user

[hlogmans]

Hi,

on non-administrator user in windows 2000 the appupdate on program start completely crashes (Ugly C++ error). It claims not to be able to access the agent.exe, multiple users reported this error.

The program was installed with ISDEV7.03, and the option to install it for all users was activated.

Please some suggestions

[hlogmans]

some extra info:

the program was installed as administrator

running as administrator works fine

[CChong]

I just wanted to chime in that I am able to duplicate this problem as well. I am running the current version (1.20) of the update service on my machine. When I log in as an administrator everything works perfectly. But on the same machine, logged in as a non-administrator I see two different problems:

1) When trying to CoCreateInstance on the Agent, CoCreateInstance fails and returns a NULL object.

2) When trying to run Agent.exe directly from the command line I receive a message box (screenshot attached):
Runtime Error!
Program: C:\PROGRA~1\COMMON~1\INSTAL~1\UPDATE~1\agent.exe
abnormal program termination

Now its easy enough to work around these problems by checking for administrator privileges before trying to use the agent, but it is not at all what I want to do.

I am in the process of investigating whether my company can use the Update Service and so far have been very happy with it. However, we need the ability to deliver messages to our users regardless of whether they are logged in as an administrator. I can understand updates not working, but we ought to be able to deliver messages. This issue alone will prevent us from deploying the Update Service to our customer base. Is there any chance of getting this functionality working by the October release?

[CChong]

OK, I need to slightly change what I said -

1) When directly executing Agent.exe everything is as I said.

2) When using the COM Interfaces, I was not seeing what happened correctly. The Agent object IS able to be instantiated and in fact all of the calls succeed, they just don't seem to do anything.
The code I am using to test this consists of two parts. There is a wrapper class called CUpdateService (that code is attached to the email) that controls the Agent object. The second part is what actually starts an update check running and is the following line of code:

CUpdateService("{743D3033-2B4D-41F7-B563-EDFE9A1F41F9}", "2.0.0").CheckForUpdates();

That GUID and Version number to exist on the Update Service right now. If I run this code as an administrative user everything works correctly and I'm prompted for an application update to version 2.0.1 of my application. When run as a non-administrative user, nothing happens.

If you then modify that code to report the current version as 2.0.1, you should receive a scheduled informative message. As an Administrative user that message does arrive as scheduled. As a non-administrative user that message is not delivered.

CUpdateService("{743D3033-2B4D-41F7-B563-EDFE9A1F41F9}", "2.0.0").CheckForUpdates();


So how exactly is this supposed to function?

[Chris_Woerner]

Unfortunately, the Update Service does require Admin Rights. Our runtime is written to the PROGRAMFILES folder, which users don't have access to. Also, we use COM which requires entries into HKLM, which users don't normally have access to. While you shouldn't be seeing the Update Service crashing with an application error, I wouldn't expect it to work.

So why do we have this requirement? As most software installations and updates require admin rights anyway, we didn't think this requirement was adding an additional burden.

Since that time, Professional 7 has found a way to install its runtime engine without admin rights. This challenges our original assumption. However, it doesn't remove the requirement that an application be designed to install without admin rights - it just means that the Professional 7 engine will install and run without admin rights.

So let me ask this question.... is there value in having the Update Service run without admin rights? Keep in mind that it may not be able to install any updates that it finds?

[CChong]

I am not talking about needing Administrative Rights to install, which I do understand. I'm talking about needing Administrative Rights to check for updates. None of the things you described cause you to need Administrative Rights during an update check.

Like most well-behaved applications our application does not need administrative rights to run. In fact most of our users are in schools and will not have administrative rights on their default accounts. However, there is great value to us in being able to deliver the message update type in those situations. Merely launching the website to present those informational updates should not require any administrative rights. In all honesty, even downloading a new update should be able to work without administrative rights, its only when the user goes to install that they need administrative access -- and at that point it is the responsibility of the update program to do that prompting.

In short, all our users run under non-administrative accounts -- if they can't receive notifications of updates then the update service is useless for our needs. They'll never see them. For example, we could use the message service to deliver a message saying that there is an update available if they logged in as an administrator.

And yes the crash should be fixed 🙂

[hlogmans]

It makes sense not to allow non-administrator users to do updates, but i would advise that the component handles this, at least for silent startup-update-check. The error displayed is a C++ error (very very ugly, win31 like, white window)...

Using VB & Delphi with COM agent

[tazochai]

I totally agree with mdouglas. I ran into this same problem this week. Our product checks for an update every 30 times the product is used. And we have a menu option that checks for updates. Now I have to figure out some way to deal with a non-admin user using the product.

[ProductManager]

I have found a work around to the problem of checking for updates when your not a admin, and it works 100% becuase I have it in production. This work around only allows the check to run, if there is an update then of course user has to then inform someone who has admin priv's to install. Here is what I did:

Under a feature (one that is required so always gets installed, if no one single feature is requried then create a feature and just have it invisible and set required to yes. Create a new component, for identigy sake called it like UpdateFolderPermissions. Then on component go to the property for destination, set the destination to - [ProgramFilesFolder]InstallShield Installation Information\UpdateService\Database. Then click the ... under property permissions and create a entry with blank domain and username of Everyone. Then highlight one of the permissions and hit select all. Then hit ok.

Don't worry about thinking it deletes that folder if it exists or anything, becuase it doesn't hurt any of the contents.

But when component gets installed it makes it so non-admins can check for updates just like Admin can, hence removing ugly error message.

[ProductManager]

I was actually applying a update on a product and I realized something in regards to this. We use Wizard UI, which work works fine.

I just did a test becuase I curious about this so I changed the UI to WEB, and darned if I didn't get the message about admin, never had this problem becuase we use Wizard.

So now this really has me curious to see if there is work around for Web. So I'm going to play around with it, but just to clarify, work around I had did works, notifies user, but in Wizard mode.

I'll post back if I find something with web

[hlogmans]

Updating these folder restrictions is a workaround that not every system administrator will admire, but for those who really need this, you have explained it well! Thanks for the input.

[ProductManager]

You are correct, most admins wouldn't admire chaning folder permissions, but I justifyed it by the reasoning that I'm really just modifying a folder that my App utilizes.

Now if I had put [ProgramFilesFolder], that would not be a good practice, but since your just modifying database folder your not intrioducing too much risk... but yes you do bring up a good point for people to consider before implementing.

[tazochai]

Thanks for the information, ProductManager. I will try that now.

[hlogmans]

What i was thinking: is it sufficient to set write permissions for just a specific .ini file (tha one that needs to be updated)? Can that be done? I don't think a system administrator would have problems with that.

[ProductManager]

You can do that within the install, peice of cake, we just need to know what file it uses, if we can figure that out we might be in business.

[Chris_Woerner]

Just fyi... we understand the problems you are experiencing. The next release of the Update Service will address this problem by following Microsoft's "Designed for XP" specification....

Microsoft recommends storing all application specific files to an 'all users application' location. This location is determined by calling a windows API. It is different on different operating systems. By default, this folder is also locked for non-admins (like Program Files). But Microsoft also recommends that the permissions be updated on this folder for applications that run in locked-down environments. So we will be updating our Agent to store the files into the recommended location and updating our installation to set the permissions on this directory so a non-admin ran update them. As these are MS recommendations, system administrators should not have issues.

[Chris_Woerner]

Just in case you are wondering.... the new Agent will move all existing files and update file permissions when it gets installed.

[ProductManager]

I know you were just waiting for this question Chris ;-)... but ETA on new Agent???