We have a test/integration environment (rig) running Windows HyperV with server VMs inside it.
I'd like to manage patches in the rig (the hyper V hosts and the VMs inside, which are all on their own domain) but we cannot connect the rig to the internet (or even our corporate network) due to security issues.
Is it possible to download the patch info for WSUS (or whatever technology/application is appropriate) from a browser and then load it into the rig manually? If not, do you have recommendations for managing patches on a server that is disconnected (and cannot, ever, under any circumstances be connected to the internet or corporate network)?
The Configure a Disconnected Network to Receive Updates chapter in the WSUS documentation describes the officialy supported way to use WSUS in a disconnected environment. You need to have a second WSUS installation which can download updates from Microsoft servers.
First you need to synchronize the metadata on the connected WSUS server; then you must make it download the update files in some way (e.g., by approving updates for some dummy group). After doing this you need to export metadata from the connected WSUS server:
Then transfer
packagename.cab
and everything in theWsusContent
folder to the disconnected WSUS server, and import metadata there:Wait while WSUS validates the update files, then work with it as usual (approve updates, etc.).
The main problem with this workflow is that there seems to be no way to transfer approvals between the disconnected WSUS server (where you can see what updates are required by clients) and the connected WSUS server (where you need to download updates).
Also see this article, which describes a recent update for the WSUS server; this update removes the 2 GB limitation on the export file size, which can be exceeded if you synchronize updates for lots of products. The update changes the export file format from CAB to gzipped XML, which does not have a 2 GB limitation.
Your options so far:
Note that a WSUS server, even when online, can be configured to present basically negligible security risk to your domain. It can be placed in the DMZ, the clients do not need to be in the same domain as the WSUS server and update signatures are checked by the clients against Microsoft's public keys, so it should be impossible to forge updates as long as the corresponding private keys are not subverted (which would pose a problem no matter if you are using WSUS to install updates or not). So you could set up an onlined WSUS server and set up your test network's filters to allow nothing but HTTP/HTTPS connections to this server without compromising security.
You cannot connect it to "the internet" due to unspecified security issues, but surely you can create a firewall rule allowing only the WSUS server to connect only to Microsoft Update servers, followed by an explicit deny any/any rule. If your colleagues/superiors believe that there is a reasonable argument against this, we would like to hear it.
In principle the following might work: Create a WSUS server and regularly
You may have a considerable delay in upgrades because it may take a few back and forth movements antil this mobile WSUS learns which of the updates are actually needed and should be downloaded.
I have an isolated network and run into the same issues. Now that our WSUS (Server2008R2 STD) won't export \ import the .cab file because it's greater than 2GB. There's no cleaning mine up... I need to provide 9,000+ updates to a classified, isolated network... I use VMwarePlayer and create a virtual Server2008R2 WSUS give it plenty of virtual drive space 150+GB then after a couple days of the virtual WSUS server collecting the updates I put the VMwarePlayer and machine on the network via sacrificial 500GB usb portable hard drive. I join the virtual server to the domain and make it the upstream WSUS. Then I change the actual WSUS to be the downstream server. After they sync\update\download (a day or so) I shutdown and delete the virtual WSUS then change the real WSUS back to the Upstream server. run gpupdate /force on all the workstations in the WSUS pool and they begin updating. This is a quarterly process, so we do a VERY LARGE update initially to these isolated systems, then the quarterly updates can be done the same way (if you want) or clean up the WSUS files and just go back to doing the wsusutil.exe export \ import with .cab files smaller than 2GB.
O totally understand where you are coming from and I have a similar situation. We have an isolated patch test rig to test updates and approve them prior to deploying in production.
So this is situation:
Our plan:
WSUSutil
)