Reseller, LockDown and Wupdate

[CMS Software]

Our biggest reseller has decided to put all it's customer's machines on lock down. All software installations are "pushed" out from their headquarters IT department. We can no longer ship CDs or send download files. The reseller has total control of the end user machines and we have no access to them.

We can reconfigure our software to handle this draconian mess except for one thing. Updates. We can't let them push out updates because they have no way to know who gets an update and who does not. They are a fortune 500 international company, but their IT department's record keeping ability is dismal.

What experience have others here had with Wupdate on locked down machines with restricted users? Is there a way to reconfigure locked down machines so that digitally signed software can do its own updates?

We don't want to lose this reseller, but we also do not want the headaches that come with wrong updates, wrong version on first install, unintended upgrades from single user to network user or vice verse, etc.

Any suggestions?

-O. D. Williams-

[linder]

Hello,

What you have to do is to change all "per-machine" configurations to "per-user". In a locked-down environment, you can't install or write to any "protected" area (e.g. Program Files folder, HKEY_LOCAL_MACHINE registry, etc.). Wupdate in combination with the IDEPLOY.CLI (see "Store Properties in INI File" Install Web Update Client option) should be able to work in a locked-down environment. Of course, if your software is located in a protected folder area (e.g. Program Files) then this will not work.

Hope this helps.

Friedrich

[linder]

BTW, on an UAC-aware operating system, the standard wupdate.exe requests administrator execution level privileges. But wucheck.exe works non-elevated.

Friedrich

[CMS Software]

Friedrich,

Thanks for the update. It almost seems we would be better off with this vendor to make a version of our software that installs in its own folder off of C: than to follow standard procedures...

Also, if I understand correctly, WuCheck only checks for an update. If there is one, WuCheck calls Wupdate to do the actual install, so you still are dealing with UAC.

Also, going to "per user" rather than "Per Machine" is a headache because of extra setup requirements. Oh, well...

-O. D. Williams-

[linder]

The standard wucheck.exe runs non-elevated and if there is an update available, it downloads and executes it. By default, it runs the downloaded program elevated (from the non-elevated running wucheck). So what you can do is to change line 203 and 205 in the wucheck.sb7 and disable the "Run elevated" option. Then compile your own wucheck.exe and distribute this one instead of the standard wucheck.exe. This allows you to provide a non-elevated running web update check and a non-elevated running update process (set the "UAC Execution Level" General Properties option to asInvoker in your update projects).

But never forget one important point ;) You can't execute any action that requires elevation (write to protected folder or registry areas, including registering OCX files, etc.).

Friedrich

[CMS Software]

Friedrich,

Thanks for the info. With SetupBuilder, there IS a way to meet the requirements of our wacky control freak reseller and still get the job done! I'll start writing the specifications for our new install/update routines right away. I sure am glad you and I are on the same team, I'd hate to have you as a competitor...

-O. D. Williams-

[linder]

<g> Thank you :)

Friedrich