There are two main options, each with an "easier" and a "harder" way to accomplish the goal depending on your requirements and networking environment.
- Downstream servers can see all available updates, but clients cannot install them until approved upstream.
This option relies on your upstream server (USS) being set to not download content until updates are approved. The downstream server (DSS) syncs from the USS as normal, and receives metadata about available updates. This enables clients to scan and determine whether updates are applicable. Administrators at the DSS can see Needed updates and can Approve the updates before or after the updates are approved on the USS. However, until the USS Approves the updates the content will not be available and clients will not be able to install them.
An alternative to this approach is to treat this as an air-gap scenario and periodically export the parent WSUS instance's metadata and binary content and import it to a stand-alone instance for the final destination. Updates are imported without approvals, so the branch office can make final determinations.
- Absolutely no content from non-approved updates flowing to the
The best approach for this is to have a stand-alone server for the downstream clients. On the primary WSUS server, updates are evaluated and KBs for approval are noted. The branch-office WSUS server can then import KBs from the Windows Update catalog by KB number directly.
A difficult-to-implement alternative to this approach is sync'ing the USS to WU and getting all the metadata for categories/classifications.
Once you identify desired updates, approve them and ensure all content has been downloaded. Use the WSUS API to delete non-approved updates. Export the DB and WSUSContent folders, then import them into a USS that doesn't sync from WU. There are a lot of moving parts to this solution, and is not attempted lightly. We've done this here as part of a commercial solution and took a while (and several people) to get right.