Monday, April 2, 2012

Allow standard users to update UPS WorldShip

I have a user who uses UPS WorldShip 2012 daily. I didn't want to give the user local admin rights on the computer, but WorldShip updates automatically and it happens more than once a week. Those updates require admin privileges to run, so I did some digging to come up with a workaround. It turns out it's possible, and is pretty easy to setup.

First, run RegAccess.exe in the UPS install folder (the standard path is C:\UPS\WSTD\RegAccess.exe) using an account with admin rights on the machine. It only took a few seconds to run.

Next, you'll need to download the Microsoft Application Compatibility Toolkit, which you can get from here. You want the ApplicationCompatibilityToolkitSetup.exe file. Install that on the machine running WorldShip, and then start the Compatibility Administrator (32-bit) program with an admin account.

From here you'll want to check out this article for instructions on how to use the toolkit. For the name of the program to update, use runpatch.exe. The vendor is UPS (Or whatever you'd like. It doesn't really matter). For the program file location, find the runpatch.exe file in the UPS folder (default is C:\UPS\WSTD\runpatch.exe).

After you run through the setup to check the RunAsInvoker option, choose save as and it will ask you for the database name. This will be the name of the sdb file you need to import, and in their case they used uac-whitelist in the example. I saved my sdb file in the C:\UPS\WSTD folder to keep it all together, but you can save it wherever you'd like.

Once you have your sdb created, you'll need to open a command prompt running with admin rights. From there you can enter sdbinst C:\UPS\WSTD\uac-whitelist.sdb and press Enter. If you saved your file somewhere else, use your path instead, and the same for the sdb file name. That will import your sdb file into the system so you no longer need admin privileges in UPS WorldShip to update the program

17 comments:

Joakim said...

Yi and thanks for an excelent article about UPS WorldShip.

But would it be possible for you to attach the SDB file on your blog also? then we wouldnt be in need of running the ACT.

Thanks and best regards

crapecodefencer said...

What's the purpose of running RegAccess.exe?

rslygh said...

RegAccess.exe is supposed to assign full access to all users for the Worldship files. I thought this would solve my problem, but it wasn't enough. I'm not sure if has any bearing on fixing this problem so you can try skipping that step if you'd like and see if it makes a difference. I ran it during my attempts to make this work though, and since it did work in the end I left it as a required step.

Anonymous said...

New Worldship version 15 has no RUNPATCH.EXE file. Your fix worked on previous versions. Not sure what will happen on this one, I ran the REGACCESS.EXE.

Peter Somers said...

WorldShip 2013 (v16) does have the REGACCESS.EXE and this fix seems to still work. I tested it and everything updated okay in a non-admin account.

Can I use the SMB file on other clients or do I need to recreate it?

Thank you.

rslygh said...

Good question Peter, but I don't know the answer to that for sure. I've only had to use this one back when I published the post in April 2012, but I don't see why you'd need to recreate the sdb files individually for each computer, unless the program being installed on them differed (e.g. 32 vs 64 bit installers). As long as it is the exact same installer file being used on all the machines I think creating one sdb and using it on all should be fine. If you happen to try it please come back and report the results.

Anonymous said...

Thanks for the article. Fix work great.

J Clay said...

Thanks for the post. I have been searching ALL OVER for this and finally found your reference on Spiceworks.

Quick note - I tried sharing an sdb file and it didn't work. Needed to create it on each machine.

Thanks again - Jim

John said...

Thanks for the guide. I was able to copy the SDB file to multiple computers and run RegAccesss and sdbinst on each one. It worked very well.

John said...

Thanks for the post, it worked great. I recently installed WorldShip 2014, and it applied the fix to one computer. Then I copied the database file, and ran regaccess and sdbinst on the other three computers.

Anonymous said...

UPS came by our warehouse to update Worldship to Worldship 2014 version 17.0.

This fix doesn't seem to allow standard users to pull patches without credentials now.

Has anybody ran into this issue with the new 17.0 version? Hopefully there is a workaround out there...

UPS doesn't like to keep security in mind...

Anonymous said...

This works with WorldShip 2014 (version 17). You need to re-generate the .sdb file for the new runpatch.exe. You may also need to uninstall the old one:
sdbinst -u c:\UPS\WSTD\uac-whitelist.sdb

rslygh said...

Thanks Anon for following up

Anonymous said...

Weird. It's working now. I think using the command to uninstall the .sdb is what I had to do. (Thanks Anonymouse) I was uninstalling it through Programs and Features.

Anonymous said...

Will this fix work on a user that uses remote access to ups worldship?

rslygh said...

Well, it should work on the machine they are using, but I would think that the Worldship server would need to be updated too. Unless the remote user will be making the updates at the server I don't know that this would help. It never hurts to try it though.

David W Franklin said...

Prior to UPS Worldship 2016, creating an Application Fix to "run as invoker" for C:\UPS\WSTD\runpatch.exe and registering the .sdb via sdbinstall.exe was all that was needed.

It appears that in UPS 2016, runpatch.exe is updated each time it is run, and there is an increment in the version number of the file.

If you take the defaults on the "matching information" window when creating your application fix - you are tying your .sdb to the version number of runpatch.exe at .sdb creation time. Since UPS is now populating and incrementing verison number at each update, your .sdb is no longer applicable.

Create a new .sdb and remove selection for any "matching information" that may change, in our example: the "version fields"