info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
"Files not downloaded" on disconnected server
247 views
Skip to first unread message
Dan Thomas
Jun 2, 2016, 5:20:34 PM6/2/16
to
I'm running Windows 2008R2 w/ WSUS 3.0 SP2 both on my internet connected server and my airgap/disconnected server
Been having trouble with the airgap server saying that files are still needed for updates. After wrestling with it for a while, I did a redo... reinstall WSUS 3.0SP2 on the disconnected server and created a new database on SQL 2008R2. The update files are still on the server and I re-ran the wsusutil import.
Still, the server is showing over 13K files (nearly 283GB) of updates that WSUS thinks needs files.
I've got my servers on both sides configured to recieve updates for Windows 2008, 2008R2, Windows 7, Windows 10, Windows 2012, Windows 2012 R2, a few versions of SQL, Silverlight, and some office products. They are both configured to store update classifications for Critical Updates, Definition Updates, Security Updates, Service Packs, Update Rollups, and Updates.
The auto approve rule is configured to approve updates for Critical Updates, Security Updates, and Service Packs.
When I check on an update that claims it still needs to download the files, I can find the referenced files in the WSUSContent directory structure.
Windows Update service is running as Local System.
I'm at a loss here. What am I missing? Why would the WSUS Service not be seeing the updates? My thought is permissions on the WSUSContent directory. Can anyone verify for me the minimum permissions needed?
Is there something else I should check?
Been having trouble with the airgap server saying that files are still needed for updates. After wrestling with it for a while, I did a redo... reinstall WSUS 3.0SP2 on the disconnected server and created a new database on SQL 2008R2. The update files are still on the server and I re-ran the wsusutil import.
Still, the server is showing over 13K files (nearly 283GB) of updates that WSUS thinks needs files.
I've got my servers on both sides configured to recieve updates for Windows 2008, 2008R2, Windows 7, Windows 10, Windows 2012, Windows 2012 R2, a few versions of SQL, Silverlight, and some office products. They are both configured to store update classifications for Critical Updates, Definition Updates, Security Updates, Service Packs, Update Rollups, and Updates.
The auto approve rule is configured to approve updates for Critical Updates, Security Updates, and Service Packs.
When I check on an update that claims it still needs to download the files, I can find the referenced files in the WSUSContent directory structure.
Windows Update service is running as Local System.
I'm at a loss here. What am I missing? Why would the WSUS Service not be seeing the updates? My thought is permissions on the WSUSContent directory. Can anyone verify for me the minimum permissions needed?
Is there something else I should check?
adrian gattorno gil
Jun 3, 2016, 12:09:43 PM6/3/16
to
really i don´t know. maybe you can try make a deep maintenance like in this blog https://blogs.technet.microsoft.com/configurationmgr/2016/01/26/the-complete-guide-to-microsoft-wsus-and-configuration-manager-sup-maintenance/
Dan Thomas
Jun 3, 2016, 1:06:43 PM6/3/16
to
Does anyone know if the WSUS service uses values in the SUSDB to determine if the files are ready to deploy? I thought about trying to manually fiddle with the file status in the database, but nothing I've tried worked. So far I've tried making a known good file set to 100% downloaded (setting BytesDownloaded = TotalBytesToDownload) and I tried setting the ActualState = 12 which seemed to agree with other files that show as downloaded (though oddly enough they list the DesiredState = 3... you'd think Actual and Desired should match when everything is good...
In any event, making both of these changes on an update with a single file didn't make the update show as downloaded in WSUS Admin Console.
In any event, making both of these changes on an update with a single file didn't make the update show as downloaded in WSUS Admin Console.
sman...@riverturn.com
Jun 3, 2016, 5:24:27 PM6/3/16
to
While this isn't exactly what you want to hear, i'd really suggest moving to W2012 and WSUS 6.3.x.x
W2012 will properly update W10 clients (if needed) and WSUS 3 isn't supported anymore (or will be desupported here quickly).
notes about WSUS 3 deprecation... (the article calls the new WSUS v4 while I call it v6 because of the internal version numbering in the product)
https://www.404techsupport.com/2015/12/microsoft-clarifies-wsus-role-windows-10-v1511-upgrade/
To your question about whether or not the DB still holds the status of files... It does...
In fact, the tbFileDownloadProgress table has the pending download files listed, and their current progress... It's not as easy as just listing the files from that table, however, and in fact I haven't 100% figured out exactly what all SQL joins are needed to get the data to look presentable but it helps you see what it's currently looking for.
Another FYI.. WSUS 6 and WSUS 3 use basically the exact same DB Schema.. I.e. some pretty heavy SQL queries developed for WSUS 3 still work for WSUS 6.
I can say that I haven't ever run an air-gapped server before, so I can't help much in that arena, but if the server can't see the files you've downloaded, it's possible an issue with where the files are stored versus where the server is looking for them... possibly a permissions issue... or something else I can't think of off the top of my head at the moment...
Is this a new development in an old server implementation? or a new install? I saw you reinstalled, just wanted to validate how long this was running previously.
Steven
W2012 will properly update W10 clients (if needed) and WSUS 3 isn't supported anymore (or will be desupported here quickly).
notes about WSUS 3 deprecation... (the article calls the new WSUS v4 while I call it v6 because of the internal version numbering in the product)
https://www.404techsupport.com/2015/12/microsoft-clarifies-wsus-role-windows-10-v1511-upgrade/
To your question about whether or not the DB still holds the status of files... It does...
In fact, the tbFileDownloadProgress table has the pending download files listed, and their current progress... It's not as easy as just listing the files from that table, however, and in fact I haven't 100% figured out exactly what all SQL joins are needed to get the data to look presentable but it helps you see what it's currently looking for.
Another FYI.. WSUS 6 and WSUS 3 use basically the exact same DB Schema.. I.e. some pretty heavy SQL queries developed for WSUS 3 still work for WSUS 6.
I can say that I haven't ever run an air-gapped server before, so I can't help much in that arena, but if the server can't see the files you've downloaded, it's possible an issue with where the files are stored versus where the server is looking for them... possibly a permissions issue... or something else I can't think of off the top of my head at the moment...
Is this a new development in an old server implementation? or a new install? I saw you reinstalled, just wanted to validate how long this was running previously.
Steven
sman...@riverturn.com
Jun 3, 2016, 5:33:01 PM6/3/16
to
...and here's a decent link for WSUS Content Dir Permissions, along with some other directories to check as well... I know I've been bitten by the Temporary ASP.NET files folder issue once or twice before.
http://www.expta.com/2008/01/fixing-incorrect-directory-permissions.html
Steven
On Thursday, June 2, 2016 at 2:20:34 PM UTC-7, Dan Thomas wrote:
http://www.expta.com/2008/01/fixing-incorrect-directory-permissions.html
Steven
On Thursday, June 2, 2016 at 2:20:34 PM UTC-7, Dan Thomas wrote:
sman...@riverturn.com
Jun 3, 2016, 5:40:13 PM6/3/16
to
and one more thing... It's entirely possible that the version of the WSUSSCN2.cab (definitions for updates and when to deploy to what os) is inconsistent with the files you are using. I don't know how you import that stuff for an airgapped environment, but it's another thing to check.
As well, Microsoft makes tiny changes to a file, and WSUS will then be looking for a completely different file for whatever update (even if it's named the same). (Note: the file name isn't what it's looking for... It's actually looking for a file hash of the downloaded file to verify the correct file is downloaded and complete, so updating the Actual and DesiredState isn't really going to work to change your problem).
As well, Microsoft makes tiny changes to a file, and WSUS will then be looking for a completely different file for whatever update (even if it's named the same). (Note: the file name isn't what it's looking for... It's actually looking for a file hash of the downloaded file to verify the correct file is downloaded and complete, so updating the Actual and DesiredState isn't really going to work to change your problem).
0 new messages