Updater Fails for Regular Users

[leeroy]

Scenario 1: Install as an admin user, run as admin user
- Updater completes without an issue and without elevating privileges

Scenario 2: Install as an admin user, run as regular user
- Update runs and appears to do nothing.
- updater.log shows:

Code: Select all

OS Version: 10.0.19045 SP0 (workstation) [x64]
CPU: Intel(R) Xeon(R) E-2176M  CPU @ 2.70GHz

# 2024-02-15 14-33-32 [PID=9792|Thread=5240]    |	Running updater. Mode: 2
# 2024-02-15 14-33-33 [PID=9792|Thread=5240]    |	OpenUrl() returned:3758096403
# 2024-02-15 14-33-33 [PID=9792|Thread=5240]    |	Connect() failed

The whole point of using this updater service was to allow regular user the ability to apply updates without elevation. The documentation seems to indicate this is possible, but we have been unable to make it work.

Kind regards

[leeroy]

We've identified a potential issue related to where updates are downloaded in the updater settings. The option to "Download updates to this folder" is set to use the "[CommonAppDataFolder][Manufacturer][ProductName]\updates\ path.

Code: Select all

Download updates to this folder: [CommonAppDataFolder][Manufacturer]\[ProductName]\updates\

Attempting to switch this to [tempFolder] doesn't yield the desired outcome, as it redirects to the temp folder of the elevated user, not the regular user. Directly specifying the regular user's temp folder works, but isn't feasible for practical use.

Code: Select all

Download updates to this folder: C:\Users\RegularUsername\AppData\Local\Temp

This might be a Advanced Installer Updater bug, and we're exploring workarounds given this context. Any assistance would be much appreciated.

[Catalin]

Hello,

Yes, it is indeed possible to install updates without elevation.

How to handle updates without elevation

However, the entire point of this is that the updater either runs as a service or as a scheduled task, implying that it has privileges already.

If you want to install the updates by double clicking the updater, this will not work, at least not without elevation.

Best regards,
Catalin

[leeroy]

Hello Catalin,

I apologize if that was not clear. We are using all the setting as outlined in, "How to handle updates without elevation", however the above symptoms are what we are observing. Is there something fundamental we have missed?

[leeroy]

Hi Catalin,

We've further pinpointed the issue to the "Notifications" feature, particularly how it handles the "Image URL". It doesn't set the permissions correctly on the downloaded image, so any subsequent "update" using the same image fails with that error "OpenUrl() returned:3758096403".

A temporary solution is to omit the image in Notifications, which seems to bypass the problem and allows updates to proceed. Although we value this feature, we'll temporarily exclude it to ensure functionality.

Kind regards

[Catalin]

Hello,

Thank you very much for your followup on this!

I'm a bit amazed to find what the culprit actually is.

If possible, could you please forward me a sample project that reproduces this & a test-case by email at support at advancedinstaller dot com so I can further test and investigate this? And, of course, after reproducing this, to create a ticket so this issue can be fixed.

Best regards,
Catalin

[leeroy]

Hi Catalin,

We'll work on providing you with a straightforward example soon. This particular case is a bit more complex because it involves the updater feature, which necessitates a web server and multiple files that must interact together.

Kind regards,

[leeroy]

Hi Catalin, an email has been sent with a link to a simplified application example.

[Catalin]

Hello Lee,

Thank you very much for the sent email, it is really well written.

For now, let's continue our thread there.

Best regards,
Catalin