updates not working

[Abusby]

Hi,

I've made 3 update assignments and none of them work.

1 is a group of office 2013 updates.

1 is a group of Windows 10 updates

1 is a Windows CBB servicing update.

All 3 of them on all machines will not deploy, all showing the following (completely unhelpful error) 

Job error (0x80240fff) received for assignment ({ABE835FB-72F0-4139-B819-3A04322EA971}) action    UpdatesDeploymentAgent    20/04/2017 08:04:08    6080 (0x17C0)
Updates will not be made available    UpdatesDeploymentAgent    20/04/2017 08:04:08    6080 (0x17C0)
Job error (0x80240fff) received for assignment ({72866dad-f2a2-46bd-87bd-a30b4b3bbf09}) action    UpdatesDeploymentAgent    20/04/2017 08:05:48    3548 (0x0DDC)
Updates will not be made available    UpdatesDeploymentAgent    20/04/2017 08:05:48    3548 (0x0DDC)
Job error (0x80240fff) received for assignment ({EDBF2A3E-4A5D-4F1C-A126-C7BD8F6E5859}) action    UpdatesDeploymentAgent    20/04/2017 08:07:23    4916 (0x1334)
Updates will not be made available    UpdatesDeploymentAgent    20/04/2017 08:07:23    4916 (0x1334)
 

Does anyone have any suggestion of how to troubleshoot this? All 3 machines are on version 1511 of windows.

[simulacra75]

Have you checked the WUAHandler.log file on all 3 client machines? What does it have to say? Are each of the client machines correctly pointing to the CM12 WSUS server? (i'm assuming that you're using WSUS in CM12). What does the registry location, HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate show? Are your clients pointing to the WSUS server in CM12?

[Abusby]

38 minutes ago, simulacra75 said:

Have you checked the WUAHandler.log file on all 3 client machines? What does it have to say? Are each of the client machines correctly pointing to the CM12 WSUS server? (i'm assuming that you're using WSUS in CM12). What does the registry location, HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate show? Are your clients pointing to the WSUS server in CM12?

Hi, Thanks for taking the time to reply. 

the WUAHandler.log file shows the following:

Added Update Source ({42FCD6F9-F5E8-460A-BC7F-C1FD8ECDB289}) of content type: 2    WUAHandler    21/04/2017 08:24:04    6824 (0x1AA8)
Scan results will include all superseded updates.    WUAHandler    21/04/2017 08:24:04    6824 (0x1AA8)
Search Criteria is (DeploymentAction=* AND Type='Software') OR (DeploymentAction=* AND Type='Driver')    WUAHandler    21/04/2017 08:24:04    6824 (0x1AA8)
Async searching of updates using WUAgent started.    WUAHandler    21/04/2017 08:24:04    6824 (0x1AA8)
Async searching completed.    WUAHandler    21/04/2017 08:25:39    7636 (0x1DD4)
OnSearchComplete - Failed to end search job. Error = 0x80240fff.    WUAHandler    21/04/2017 08:25:39    1268 (0x04F4)
Scan failed with error = 0x80240fff.    WUAHandler    21/04/2017 08:25:39    1268 (0x04F4)
 

the registry key lists the config manager server (which is also hosting WSUS)

[simulacra75]

Okay, the error, 0x80240fff, is a catch-all, generic error. A full list of error codes and their meanings are available here (for future reference). What i would suggest moving forward is to; 

1). Stop the wuauserv service on the client machine

2). Delete the contents of c:\windows\softwaredistribution on the client machine

3). Start the wuauserv service again on the client

4). Initiate a Software Updates Scan cycle from the control panel applet, just Run, control smscfgrc (quick way of opening the applet)

5). Monitor the Wuahandler.log file on the client and the IIS logs on the Primary Site that the client is a child of, usually located in c:\inetpub\logs\<IIIS-ID-OF-WSUS-WEBSITE>\

[Abusby]

On 4/21/2017 at 0:31 PM, simulacra75 said:

Okay, the error, 0x80240fff, is a catch-all, generic error. A full list of error codes and their meanings are available here (for future reference). What i would suggest moving forward is to; 

1). Stop the wuauserv service on the client machine

2). Delete the contents of c:\windows\softwaredistribution on the client machine

3). Start the wuauserv service again on the client

4). Initiate a Software Updates Scan cycle from the control panel applet, just Run, control smscfgrc (quick way of opening the applet)

5). Monitor the Wuahandler.log file on the client and the IIS logs on the Primary Site that the client is a child of, usually located in c:\inetpub\logs\<IIIS-ID-OF-WSUS-WEBSITE>\

1) tried it (there are over a hundred machines with this issue).

2)tried it...

3)tried it..

4) tried it..

5) yes i've been looking in the logs, only contain the error  0x80240fff. The logs on the server itself? anyone in particular? there are two directories in /logs. neither of which have any entries corresponding with the clients attempt to access.

thanks for replying, but I'm just going to write this off. Its easier and faster to re-image all the machines during the next term break. At least that feature works out the box, unlike my experience of the update system.

 

[simulacra75]

If you have over 100 machines with this issue then it's likely you have a problem with your WSUS setup. Are you positive that your Software Update Point is installed and configured correctly on the Primary Site server?

In relation to the log files for IIS. Each IIS website has a unique ID. This unique ID can be seen when you right click on a website in IIS and then select "Manage Wesbite", and then "Advanced Settings". A new dialog box should open and the unique ID is listed in the ID field. Let's just say that the ID is equal to "1234567890". The corresponding log files for this website would be normally located in c:\inetpub\logs\LogFiles\W3SVC1234567890\

So, in your case you need to find the unique ID of the "WSUS Administration" website in IIS on your Primary Site server. I would also suspect that re-imaging won't necessarily resolve your problem. If over 100 machines have the problem, then it's more likely that there aren't 100 machines with an issue, there's an issue on the backend infrastructure that's preventing these 100 machines from functioning correctly. Could be wrong though.

[joma]

Had the same issue. Saw this reply in a Reddit thread: 

So I declined all 1703 updates in WSUS, and my clients started updating again! Happy days!

I think the reason for my problems were that the 1703 feature update does not supersede the 1607 update, so the SUP basically sends out two conflicting updates to the client and it just flips out.

But I'm not really comfortable having declined updates in WSUS, is there any good way of declining the updates in SUP? Or at least filter out the 1703 updates until they supersede the 1607 update?

 

[Abusby]

On 4/26/2017 at 10:26 AM, simulacra75 said:

If you have over 100 machines with this issue then it's likely you have a problem with your WSUS setup. Are you positive that your Software Update Point is installed and configured correctly on the Primary Site server?

In relation to the log files for IIS. Each IIS website has a unique ID. This unique ID can be seen when you right click on a website in IIS and then select "Manage Wesbite", and then "Advanced Settings". A new dialog box should open and the unique ID is listed in the ID field. Let's just say that the ID is equal to "1234567890". The corresponding log files for this website would be normally located in c:\inetpub\logs\LogFiles\W3SVC1234567890\

So, in your case you need to find the unique ID of the "WSUS Administration" website in IIS on your Primary Site server. I would also suspect that re-imaging won't necessarily resolve your problem. If over 100 machines have the problem, then it's more likely that there aren't 100 machines with an issue, there's an issue on the backend infrastructure that's preventing these 100 machines from functioning correctly. Could be wrong though.

I installed WSUS, then installed the software update point to control it. I didn't do anything else. I've since managed to deploy normal updates (didnt make any changes to the infrastructure, just did a fresh install from an ISO. I remain unable to deploy any upgrades however)

I'll check those logs again though.

[Abusby]

On 4/26/2017 at 11:29 AM, joma said:

Had the same issue. Saw this reply in a Reddit thread: 

So I declined all 1703 updates in WSUS, and my clients started updating again! Happy days!

I think the reason for my problems were that the 1703 feature update does not supersede the 1607 update, so the SUP basically sends out two conflicting updates to the client and it just flips out.

But I'm not really comfortable having declined updates in WSUS, is there any good way of declining the updates in SUP? Or at least filter out the 1703 updates until they supersede the 1607 update?

 

I've not opened the WSUS console or changed any settings within it because I'm using configuration manager to operate it. I have however, only been deploying one version update to the machines.

[simulacra75]

58 minutes ago, Abusby said:

I installed WSUS, then installed the software update point to control it. I didn't do anything else. I've since managed to deploy normal updates (didnt make any changes to the infrastructure, just did a fresh install from an ISO. I remain unable to deploy any upgrades however)

I'll check those logs again though.

I'm assuming you've installed KB3095113 and KB3159706 as part of your WSUS installation process?