views:

120

answers:

5

I'm working on creating a self updating application and one issue I'm running into on Vista and Windows 7 is needing to have admin privileges in order to update the client. I've run into issues with clients that have their users running under restricted permissions and they would have to have IT log onto every machine that needed to update the client since the users were not able to.

A possible work around I'm considering is to have the launcher application installed into Program Files as normal, and having the real application that it updates installed in the users documents somewhere, so that they could update and run new versions without IT becoming involved.

I'm wondering what potential gotchas I'm missing here or what I should be aware of before heading down this path. I'm aware that click-once does something very similar, and I'd be using it, except I need the ability to do silent updates, without any user interaction.

A: 

A loader stub is a good way to go. The only gotcha is when you have to update the loader; the same initial problem applies (though that should be pretty infrequent).

One problem that I can think of off the top of my head is that you're stepping outside the entire idea of keeping things more "secure." Since your executable exists in a location that should be completely accessible to a non-administrator, it's possible that something else could slam your exe thus subverting security.

Michael Todd
+1  A: 

This is how it is supposed to be. The last thing most IT departments want is a user randomly updating a piece of software. This could have all sorts of unintentional side effects such as incompatibility with the older version's files, new and possibly insecure functionality, etc. This is why IT departments disable Windows Update and do their updates manually in a controlled fashion.

If the users want an updated version of the software they should be requesting it from their IT department. Those computers and infrastructure don't belong to them, they're simply borrowing time on them from the company they work for so they can do their job.

Soviut
I agree with you in theory. Part of the problem is our development process which is release early, release often. We already have a process which will detect an update, and then prompt the download and launch of the installer to update it. This has caused a problem with one client in particular who has the computers locked down and IT has to do the updates. Since we have roughly an update a week, this has been quite annoying for their IT department. Their IT department complaints has been the reason to go down this path.
Timothy Strimple
I recommend working with them to make deployment across their networks as painless as possible. If they're updating everything by hand, they're doing it the hard way.
Soviut
+1  A: 

Is there an issue with having only one installation of your program? Is it particularly large, for example?

Do you require admin privileges to run your program?

If not, odds are you don't need the Program Files folder.

I suggest you forgo installing to Program Files entirely and just install your program into the user's folder system at <userfolder>\AppData\ProgramName.

If you happen to be using .NET, look into the ClickOnce deployment mechanism. It's got a great self-updating feature that'd probably make your life a lot easier.

Edit: Just saw your last sentence. ClickOnce can force the user to update.

Randolpho
There are actually two separate apps I'm working on. One is a kiosk that needs to be able to update without any user interaction at all. Clickonce requires that the user clicks a couple times to install the update, so it doesn't fit my requirements for that application, and I was hoping to use the same update method for both applications.
Timothy Strimple
Well, I still think ClickOnce would be the best solution -- a completely silent update isn't exactly the best UI, IMO -- but you could still solve your problem by installing to the user's folder system rather than to the Program Files folder. Your program runs with the user's permissions, and the user can read/write to AppData no problems. Badabing, badaboom, no need to elevate.
Randolpho
+1  A: 

A couple of things:

If you decide to move your app to some place in documents, make sure that your application writes data transparently to where your program is installed, e.g. if there are hard coded paths anywhere in the code that are pointing to bad places. Perhaps this is not an issue for you, but might be something to keep in mind.

We solved this in pretty much the same way when we decided to implement a "live update" feature. But instead we installed a service which is running with administrator rights. This service in turn can run installers once the program needs to be updated. With this type of solution you don't even have to move your applicaton out of program files.

Cheers !

Edit:

Another neat thing with having a service running as administrator. Is that you could create a named pipe communication with it and have it do things for you, like you wouldn't be able to do as a normal user.

Magnus Skog
A: 

You can probably leverage AppLocker. It may only be for Win7 though I'm not running Vista any more. ;)

RandomNickName42

related questions