What would keep updates that have been approved for install from downloading to WSUS? I have a couple machines that can't get their updates simply because it can't be downloaded. Says it could be a permissions issue but I don't see the update on the harddrive of WSUS. Could this be related to my recently added Automation server and group management changes?
I've got none of the event 364.
When I use update management and attempt to approve or decline an update it does attempt to change the status but throws a failure. When I go back to the main data grid and right click the update and click approve to change it's approval it returns a success. Thought when the client attempts to download and install this update it fails.
If there are no EventID 364s in the AppEventLog of the WSUS server, then it's not failing to download the updates... but it may be downloading slower than you anticipated.
What was the information that led you to believe the update downloads were failing?
The error message under task history says that it's either the permissions to the download directory or that the downloads are failing to download properly.
Sent from my iPad
The Patch Manager Task History would not record any information with regard to the WSUS Server downloading updates from Microsoft, that I'm aware of.
Can you screencap what you're seeing in Task History and post it here. Perhaps if I see it it will trigger something that I'm not remembering mentally.
This is a CLIENT-SIDE error. It's saying that the WUAgent cannot download the file for that update from the WSUS Server because it does not exist on the WSUS server -or- the access permissions on the content store are incorrect.
Now that we know that it is the client that's recording the HTTP 404 error, we also know a couple of other factoids. We know that the WSUS server did successfully download the file for this update at some point. If it had not, the client would have never been able to see this update as available and attempt to download the file. So the question is: Which is the culprit.. permissions or a missing file.
First step is to inspect the filesystem on the WSUS server and determine the actual state of the file for KB2705619 related to Windows 7 x64 systems.
Concurrent with that, run the FREE Diagnostic Tool for the WSUS Agent and verify whether the content store is legitimately accessible.
If the file is physically missing, then run the utility wsusutil reset from %ProgramFiles%\Update Services\Tools, which will reconcile the content store with the list of approved updates, and re-queue downloads for any missing files.
If the file is not missing, then we're back to the accessibility of the content store.
On the approval question...
Using Update Management to Approve/Decline an update is a bit tricky. So since it works as expected from the Update View, let's work from the presumption that this is about the usability in the Update Management tool and not core WSUS or Patch Manager-to-WSUS functionality that is impacted.
When you launch the Update Management task, preferably, the first requirement to issue approvals is that an update is populated in the list. This would naturally occur if you selected an update from an Update View and launched the task, or selected an update from the Update Details tab of a Computer View and launched the task. If the Update Management task does not have any selected updates, then you'll need to use the Select Updates dialog to explicitly add one or more updates by navigating through the WSUS catalog -- which quite frankly, is a pain -- mostly because of the volume of updates in the catalog. As a matter of UI design, the Approve/Decline buttons should be disabled with an empty update list, and I'll send that to the product team to record as a 'bug'.
With updates selected prior to launching the Update Management task, and then after launching the Select Updates dialog, the Selected Updates pane of the dialog will be populated with the update(s) selected from the Update VIew. At this point, clicking on Approve without selecting updates from the Selected Updates pane will generate a warning dialog (the same one we should generate with an empty list). Select one or more updates from the Selected Updates pane and click on Approve or Decline.
There is one additional consideration here, which can impact which WSUS Server view you select the updates from. Since you cannot approve update on a replica server, if you select updates from a replica server view, the dialog will attempt to issue those approvals to the replica server, and they will fail. In the toolbar of the Select Updates dialog, click on Apply to Update Server and verify that the displayed WSUS server is the upstream server, or select the updates from an Update View associated with the upstream server.
If none of that addresses the behaviors that you are observing, then I would encourage you to open a ticket via the Customer Portal so that a Support Rep can investigate further, and perhaps observe via GTM.
Now here's something strange, I try to approve or decline those updates that won't download and Patch Manager can no longer change those approval statuses. Something wrong with Patch Manager instead?
I'm getting a whole slue of Fault Bucket, type 0 failures for WindowsUpdateFailure. The ACL is set to everyone having read access. I'm unsure about the router but it shouldn't have been changed recently.
By far, the single most common cause for updates that have been approved failing to download to the WSUS server is because an intervening device (proxy, webfilter, router) is not configured to fully support the HTTP v1.1 protocol specification (which, btw, is now 13 years old) with respect to Range Protocol Headers. Microsoft BITS is dependent upon the use of Range Protocol Headers to do download resumes. This issue typically manifests on larger downloads because that's where the range definitions are used. SonicWall appliances are noteworthy for having this issue.
Other significantly lesser occuring conditions are defective ACLs on the WSUSContent folder, misconfigured quotas, and when the ~\WSUSContent folder is hosted on a non-SYSVOL volume, the Network Service account needs READ access to the root of that volume, which is not configured by either the .NET2 installer or the WSUS installer.
The actual cause for each individual download failure is logged in the Application Event Log of the WSUS server.
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 150,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process.