Update Without Admin PrivilegesAnswered

This is my problem.I need to install the application to all users.The application uses windows authentication (by active directory), and application users access that from multiple machines of the institution, in different locations.This makes impossible the installation for a particular user ...Is there another solution?

Thank you.

If you want to install to a directory that typically requires admin permission to move files there, but you don't want wyUpdate to prompt for a password, then you only option is to use a Windows Service. That is, create a dummy Windows Service that launches wyUpdate and installs the update. See one of the 2 following articles:

• AutomaticUpdater tutorial for Windows Services and Console Apps
• How to Silently update a Windows Service

Is there the possibility of performing the update through the user name and password of an administrator directly through the code?

Thank you.

If you run wyUpdate from an app that has admin privleges then you don't need to prompt for a username and password at all. Another option is to launch wyUpdate from a limited app, but launch wyUpdate with the credentials of an admin user.

There are a number of Windows APIs that can do this. But this is complicated and overkill for most users.

Yet another question about the update without admin privileges. I have an application installed in C:\TIS IATCC folder which is writeable by all users (Windows domain). However, the update always fails.

It goes like this:1) I manually run the wyupdate.exe2) new update is detected3) after Install is clicked, dialog appears where I need to choose the user to run the process with4) I choose the current user (Windows domain user) and click OK5) Error dialog appears telling me I need to have admin privilegies to perform the update.

Why?

Remarks: OS - Win XP, user folder is located on network share

Update on previous post: On another computer I was able to dig out error message stating something about insufficient privilegies to C:\Documents and Settings\spiller\wc\6\xxxx.wyc or something like this. I did not magage to reproduce it again. I had to delete the wc folder to get the application working again.

Hey Petr,

You've got an interesting case here. The short answer is that this would work with wyUpdate in standalone mode rather than using the AutomaticUpdater.

The reason this is the case is that the AutomaticUpdater caches the updates to a folder that the current user has access to with the assumption that if wyUpdate needs to elevate as an admin user on your computer that the admin user will also have access to those folders.

The particular folders are:

%appdata%\wyUpdate AU%userprofile%\wc

Now, because you're using a user that doesn't exist on your computer this assumption isn't true. That is, your admin user has access to the installation folder but not to the folder the updates were cached to.

Does this make sense?

I don't think I understand I cannot use the standalone mode, since its huge step back in terms of user comfort.

What part of update process requires elevated privilegies? As far as I can see, the update fails when files are being extracted.

Only the actual installation of the update requires admin privileges. Does the user you've selected actually have admin privleges?

Also there is no way an ordinary user gets elevated since the users are restricted by domain policy I guess. I mean they simply cannot run the wyupdate.exe with Run as administrator option for example.

So answer to your question is no, the users cannot get admin privilegies.

Ok, then the options are to store your app files in a directory that's in the %userprofile% path (e.g. Desktop, AppData, Documents folder, etc) or add an admin user to the computer.

Well, I'll try it. Thank you for advice. P.

Hi again, I did following:

1) Moved the application to the AppData folder and it works just fine

2) I changed NeedElevationToUpdate() method in frmMain.UserElevation as follows, and it works too!. However, only in standalone mode. Update from application level crashed :-/

bool NeedElevationToUpdate() { return false; }

So I would like to ask you, if is it possible to add command line switch to the official release thus having an option to disable user elevation at all.

Thank you!

So I would like to ask you, if is it possible to add command line switch to the official release thus having an option to disable user elevation at all.

No, it's a bit too hacky to be a feature. A proper solution would be to detect the modified permissions of the "base directory" to see if the limited user has access to it. We'll see if we can do this in a way that doesn't slow down the updating process.

I know it's quite a hack, but I'm pretty f****d up then The application is already deployed to 100+ sites and there is no way I can move it away to user folders. Please, would you mind building me wyUpdate.exe with disabled user elevation? I may send you a payment for you effort. Thank you.

No, if we implement this hack then people will start using it. However, you're free to implement it yourself. See How to make a custom version of wyUpdate.

We'll see about adding proper detection of user permissions for non-admin users installing to non-userprofile folders.

I would like to, but even if I download, compile unmodified project v2.6.14 and replace the wyUpdate.exe in the installation forlder the update fails to start returning "wyUpdate failed to start" error message. The project is built with the same version of .NET as selected in wyBuild project. However, starting the compiled wyUpdate.exe manually works just fine

My code is like this:

private static wyDay.Controls.AutomaticUpdater automaticUpdaterUse;...automaticUpdaterUse.DownloadingOrExtractingFailed += new wyDay.Controls.FailHandler(automaticUpdaterUse_DownloadingOrExtractingFailed);...static void automaticUpdaterUse_DownloadingOrExtractingFailed(object sender, wyDay.Controls.FailArgs e) { LOG.Error("TisAutomaticUpdater DownloadingOrExtractingFailed: " + e.ErrorMessage); if (state == TypeState.TestDownloadServerFile || state == TypeState.TestDownloadDataFile) { Splasher.Status = e.ErrorTitle; System.Threading.Thread.Sleep(3000); } Splasher.Close(); state = TypeState.IsError; }

Ahh, I got it work somehow. Ignore my last post then 😐