"Local Update Publisher allows system administrators to publish their own updates to Windows Server Update Services using local publishing."
Pros:
Consolidates management and storage (one console, minimal Group Policy fiddling, no separate fileshare.)
Users can install updates on their schedule and/or admins can force schedule.
Cons:
Relies on a (small?) 3rd party project. (Though open-source, and using an official Microsoft API.)
Can't assign or offer to users, only per machine.
This tutorial assumes you have a working install of WSUS, and a basic knowledge of .MSI packages.
Remember everything is stored on your WSUS server, LUP is "just" a gui that talks to it, similar to the WSUS admin console. So download and install the EXE, run it (you will need to "Run as Administrator"), point it at the WSUS server ("Localhost" if you're on the server, in our case "guard.ourdomain.com", port 80, no SSL for now), and go!
To publish:
First, acquire your MSI. In this example, we'll use the Frontmotion - supplied package of Firefox.
Select Tools -> Create Update. Point it at your .MSI. Confusingly, you *DON'T* provide the "MSI Path". (This is only if it is contained in an .EXE).
LUP (WSUS?) requires a Vendor and Product to be defined. Fill in any other details you think are relevant.(I like to include the version number in the name.)
You can then click through the next few screens, accepting the defaults for now. (These let you write more complex rules, to only target x64, for instance.) Click "finish". You'll get a progress window as it re-packages it for WSUS and uploads it the server.
Notice in this example there are now two versions of the package. Be sure to retire/remove the old version, or else clients will do weird things, i.e. continually install one then the other in the case of Firefox updates.)
Now, we just approve this update (in this case, only for the METRO-TEST group:
Now to see the results of our labor, first we have to assign our testing machine to the METRO-TEST WSUS group.Open up the WSUS admin console, find your target machine(s), right-click and give them membership the appropriate group.
From the LUP wiki:
"The WSUS clients have a locally stored cookie that stores the groups that the client is associated to. Until that cookie expires the client will not create a new one. This means that if you add clients to a group and then immediately try to force a client in that group to detect updates it will likely not find updates you have approved for your new group. You can either wait an hour or force the cookie to expire by running wuauclt with the /resetauthorization flag."
Once I did this, then re-ran "Check for updates" (CLI version: "wuauclt /detectnow"). Looks promising...
Now, go forth and publish!
