Windows Update: Error 1611: -106. Failure

[gestay]

I have 4 Windows Windows Server 2012R2 servers that are failing ‘Chceck available updates’. I can logon to the servers no problem so it’s not a permissions issue. Has anyone else run into this problem? Thank you.

Remote Agent Log

RDSSCL01 09/28/2017 10:56:20

::Begin online search – Server Selection: Default

-106G: Update search completed with errors: -2145123271

RDSSCL01 09/28/2017 10:57:17

All Messages

Thu-10:57:20> Windows Update: Error 1611: -106. Failure

Thu-10:57:20> Windows Update: -106G: Update search completed with errors: -2145123271

Thu-10:56:20> Windows Update: Executing BatchPatchRemoteAgent.exe…

Thu-10:56:20> Windows Update: Attempting to initiate Windows Update (Action: Search for updates: ‘SoftwareOnly’ | Server selection: Default / Managed) …

Thu-10:56:20> Windows Update: Establishing connection…

Thu-10:56:20> Windows Update: Initializing…

Thu-10:56:20> Windows Update: Queued… (Check for available updates)

---

[doug]

I would suggest that you start by seeing if you are able to install updates at the control panel of any of these computers *without* using BatchPatch or if you get a similar error when performing the operation directly on the computer. Let me know what happens.

-2145123271 == 0x80240439

Some of these search results might also help: Google 80240439

[gestay]

I have no problem installing patches manually.

[doug]

Are you using a local WSUS or are the searches being performed on Windows Update/Microsoft Update? Please try both (you can change the setting under ‘Tools > Settings > Windows Update’ in BatchPatch. I’d like to know if the issue only occurs with one or the other or both.

Please review the following posting about 106G. I don’t believe we have ever seen or heard of your particular HRESULT -2145123271, and I don’t believe we have ever seen 106G occur on Windows 2012R2. However, the 106G we have seen just a handful of times with customers. The 106G indicates that there was an error retrieving the search results from the update server, while the HRESULT value is the reason code. There may be a solution/resolution in this posting:

Error 106G

Also, if you are able to retrieve the relevant lines from your WindowsUpdate.log (C:WindowsWindowsUpdate.log) from the target computer, they might help shed some light. I would suggest searching for 80240439 in the log file to find the appropriate lines. Feel free to share your findings here.

-Doug

[dennis]

Doug,

I’m seeing the exact same error message as gestay. We don’t have drivers included in our WSUS repository and have a standalone Win 2012 R2 WSUS. Searching and downloading updates locally on a Win 2016 server works fine. If I search for updates through BatchPatch I’m getting the error message below:

13 November 2017 – 10:18:55> Windows Update: Error 1620: -106. Failure

13 November 2017 – 10:18:55> Windows Update: -106G: Update search completed with errors: -2145123271

13 November 2017 – 10:18:30> Windows Update: Executing BatchPatchRemoteAgent.exe…

13 November 2017 – 10:18:29> Windows Update: Attempting to initiate Windows Update (Action: Search for updates: ‘SoftwareOnly’ | Server selection: Default / Managed) …

Would be great if we can resolve the issue because otherwise we will have serious issues to keep our infrastructure up to date.

Let me know if you need additional logs or information.

Dennis

[doug]

Please review the following posting about 106G. The 106G indicates that there was an error retrieving the search results from the update server, while the HRESULT value is the reason code. There may be a solution/resolution in the following posting. You are seeing a different HRESULT, which we have only ever seen or heard of from gestay. The following posting discusses solutions for the same 106G but a different HRESULT. However, I think your problem will be resolved in a similar way. You might even just decide to build a new WSUS (or rebuild your existing one) because that might be the quickest/simplest fix:

Error 106G

[dennis]

Doug,

I built up a new WSUS server using Windows Server 2016 from scratch and repointed several Windows 2016 servers to that new WSUS server. After they reported their patch level I released like 20 patches to them.

If I use Windows to look for patches they are offered to download. If I use BatchPatch to trigger the update search I’m getting the exact same error as in my previous post.

It seems like that issue is related to BatchPatch and neither to the Windows Server nor the WSUS server.

Dennis

[dennis]

Doug,

I want to provide you more information about what else I have tested and found out:

My previous tests were done on servers in Germany. They are all built with EN_US Windows images (no language pack) but use German time and region settings. As we’re using the exact same VM template in US I wanted to give it a try to test with a Windows 2016 server in US.

The weird thing is that a Win 2016 server in US is able to be patched by Batchpatch. It is the exact same platform (VM and WSUS) and 100% identical except the region and time settings.

After I modified the time and region settings on one of our servers in Germany the error message in Batchpatch changed. Not sure if all those information can help you in any way but I wanted to provide them to you.

The error I’m getting right now is the following one:

16 November 2017 – 15:20:00> Windows Update: Error -102: Failed to execute the search.

16 November 2017 – 15:19:54> Windows Update: Executing BatchPatchRemoteAgent.exe…

16 November 2017 – 15:19:54> Windows Update: Attempting to initiate Windows Update (Action: Search for updates: ‘SoftwareOnly’ | Server selection: Default / Managed) …

16 November 2017 – 15:19:54> Windows Update: Establishing connection…

16 November 2017 – 15:19:54> Windows Update: Initializing…

So for me it seems not to be infrastructure issue in general.

Dennis

[doug]

Thanks for the information, Dennis. 106G generally means that the XML data that is being returned by the WSUS to the client has something wrong with it. In your case the particular HRESULT is not documented anywhere, but I believe it’s still likely to be a very similar cause as the one described in this link: Error 106G

I understand that you rebuilt the WSUS. I also understand that when you check for updates using the Windows Update control panel directly on the target computer that it does not have the same issue. This is because Microsoft has a private API that they use that we (and other third party vendors) do not have access to. And so it is unfortunately not possible to directly compare the results that are obtained when using the public API with the ones that are obtained when using the private API.

The problem, I suspect, is related to a particular update that has been approved. The link above (I also linked it in my previous posting) has very detailed information on how to (most likely) solve the problem. Rebuilding the WSUS was not meant to be a complete solution, and I’m sorry if I was not clear about that. Rebuilding the WSUS was to help figure out which approved update is the culprit rather than trying to figure it out on an existing WSUS that has potentially thousands of approved updates. I would suggest that you still please read the entire aforementioned link for a general understanding of the issue. Then I would suggest that you decline all of the ~20 updates that you approved on the new WSUS. Wait a few minutes after doing that because all SQL activity on the WSUS server has to complete/stop before the declination will be complete in the WSUS database even though the WSUS GUI will appear to indicate that the declination is instantaneous. Once the declination is truly complete and all SQL activity on the WSUS stops, then you can do a new check for available updates in BP. At this point the search should complete and there should be no updates found because there are none approved. Then starting with one update at at a time you can approve just the one update. Then wait a couple of minutes until all SQL activity stops on the WSUS, and then test BP again. The goal is to find which update is causing the problem by approving just one update at a time and testing the BP check for available updates in between each approval. But it’s also important to wait until SQL activity stops after initiating the approval (or a declination) because otherwise you will get misleading results if you initiate the BP check for available updates too soon after making the approval or declination.

Now, since you did not receive the exact same HRESULT that is described in Error 106G, I cannot guarantee that the problem will be fixed by finding a problematic update and declining it. However, at the same time, we have not yet experienced or reproduced this problem here. I understand that it seems to be affected by using the German time and region settings, so it is something that we can try to reproduce and test here, but it will take some time. Also, it’s important to understand that with 106G, it’s not likely something that we can fix/change/modify in our code, because the problem is that the search result that the WSUS server sends back to the client during the update search is what has problems, not the BP code. The key is to find out what is causing the WSUS to return unusable results, and in the past the issue seemed to always come down to a particular problematic update on the WSUS. And in your case there seems to also be a relationship to the German time/region setting. As a start it would be very helpful if you are able to provide me with the following information:

1. A list of all the ~20 updates that you approved on the new WSUS.

2. The exact OS version and build number of the WSUS server. The easiest way to provide this info would be by using BP ‘Actions > Get info > Get OS version’

3. The exact OS version and build number of the target computer.

---

With regard to the -102 error that you got, what is the HRESULT value? This will appear in the ‘Remote Agent Log’ column and in the BatchPatch.log file on the target computer. Am I understanding correctly that this error appeared after you changed from German time/region to US time/region on the target computer? I think we will have to evaluate this error somewhat separately from the other error because -102 generally means that there is a communication problem between the target computer and the WSUS. Therefore it seems less likely that the two issues are directly related, though I do understand that based on your testing it seems that the -102 only appeared after you made the change the to region/time settings, so we will see what we can figure out.

[dennis]

Doug,

I will have once more a look to the article you mentioned within the next days and see if I will find a solution there. The strange thing to me still is that Batchpatch works for some of the servers and for some it doesn’t work even if these servers all use the same infrastructure.

For the moment I will provide you your requested information:

1.

Service Pack 2 for Microsoft Office 2010 (KB2687455) 32-Bit Edition Service Packs 75% Install (1/3)

2017-06 Cumulative Update for Windows Server 2016 for x64-based Systems (KB4022715) Security Updates 50% Install (1/3)

2017-06 Update for Windows Server 2016 for x64-based Systems (KB4023834) Critical Updates 50% Install (1/3)

2017-05 Cumulative Update for Windows Server 2016 for x64-based Systems (KB4019472) Security Updates 50% Install (1/3)

Cumulative Update for Windows Server 2016 for x64-based Systems (KB4015217) Security Updates 50% Install (1/3)

2017-07 Cumulative Update for Windows Server 2016 for x64-based Systems (KB4025339) Security Updates 50% Install (1/3)

2017-08 Cumulative Update for Windows Server 2016 for x64-based Systems (KB4034658) Security Updates 50% Install (1/3)

2017-08 Update for Windows Server 2016 for x64-based Systems (KB4035631) Critical Updates 50% Install (1/3)

2017-11 Cumulative Update for Windows Server 2016 for x64-based Systems (KB4048953) Security Updates 50% Install (1/3)

Update Rollup for Skype for Business Server 2015, SmartSetup (KB3061064) Updates 0% Install (1/3)

2017-10 Cumulative Update for Windows Server 2016 for x64-based Systems (KB4041691) Security Updates 50% Install (1/3)

2017-09 Cumulative Update for Windows Server 2016 for x64-based Systems (KB4038782) Security Updates 50% Install (1/3)

Cumulative Update for Windows Server 2016 for x64-based Systems (KB4016635) Updates 50% Install (1/3)

Update for Windows Server 2016 for x64-based Systems (KB4013418) Critical Updates 50% Install (1/3)

Update for Windows Server 2016 for x64-based Systems (KB3199986) Critical Updates 50% Install (1/3)

Cumulative Update for Windows Server 2016 for x64-based Systems (KB3197954) Critical Updates 50% Install (1/3)

Update for Windows Server 2016 for x64-based Systems (KB3199209) Critical Updates 50% Install (1/3)

Cumulative Update for Windows Server 2016 for x64-based Systems (KB3194798) Security Updates 50% Install (1/3)

Cumulative Update for Windows Server 2016 for x64-based Systems (KB3200970) Security Updates 50% Install (1/3)

Cumulative Update for Windows Server 2016 for x64-based Systems (KB3201845) Critical Updates 50% Install (1/3)

Cumulative Update for Windows Server 2016 for x64-based Systems (KB3206632) Security Updates 50% Install (1/3)

Cumulative Update for Windows Server 2016 for x64-based Systems (KB4013429) Security Updates 50% Install (1/3)

Update for Windows Server 2016 for x64-based Systems (KB3211320) Critical Updates 50% Install (1/3)

Cumulative Update for Windows Server 2016 for x64-based Systems (KB3213986) Security Updates 50% Install (1/3)

Cumulative Update for Windows Server 2016 for x64-based Systems (KB3213522) Updates 50% Install (1/3)

2017-11 Update for Windows Server 2016 for x64-based Systems (KB4049065) Critical Updates 50% Install (1/3)

2.

WSUS server: Microsoft Windows Server 2016 Standard 10.0.14393 (SP0) [x64-based PC]

3.

Client to be patched: Microsoft Windows Server 2016 Datacenter 10.0.14393 (SP0) [x64-based PC]

The information below is an extract from WindowsUpdateLog generated by Powershell and also out of Event Viewer:

2017.11.17 13:38:21.1314031 3288 3776 ComApi *RESUMED* Search ClientId = BatchPatch

2017.11.17 13:38:21.1331135 3288 3776 ComApi Updates found = 0

2017.11.17 13:38:21.1331143 3288 3776 ComApi Exit code = 0x00000000, Result code = 0x80072F8F

2017.11.17 13:38:21.1331148 3288 3776 ComApi * END * Search ClientId = BatchPatch

2017.11.17 13:38:21.1340933 3288 2220 ComApi ISusInternal:: DisconnectCall failed, hr=8024000C

Windows Update failed to check for updates with error 0x80072F8F.

[doug]

The 8024000C is normal and not a concern.

However, I don’t think I have ever seen 0x80072F8F before. It translates to:

0x80072F8F -2147012721 ERROR_INTERNET_SECURE_FAILURE ErrorClockWrong

One or more errors were found in the Secure Sockets

Layer (SSL) certificate sent by the server.

I’m not sure if the 0x80072F8F error has anything to do with the problem you are encountering. It might, but it might not. The error that is being returned to BatchPatch, according to your original posting, is not the same, so I don’t know if one has anything to do with the other.

Googling I found the following link, which has some potentially helpful information that might explain why you have the issue with only some computers:

https://social.technet.microsoft.com/Forums/windows/en-US/ef49580b-8d8f-4bae-9d73-6bf32ba4d463/windows-update-not-running-in-windows-2012-r2-0x80072f8f?forum=winserver8gen

[dennis]

Doug,

I could finally figure out why BatchPatch is working on some of the servers and on some not.

The US servers are not as restricted in www access as our servers in EMEA. Therefore BatchPatch was able to trigger Windows Update to look for updates against Microsoft servers instead of internal WSUS server. As soon as I enable one of the EMEA servers to have web access BatchPatch works as well for this server.

But as we don’t want to have Microsoft update server as source for our Windows updates I’m back at the original problem. BatchPatch is not able to communicate through the Windows Update client to the WSUS server and report back the result. That procedure worked for Windows Server 2012 R2 and previous versions but seems not to work for Windows Server 2016.

Have you been able to reproduce the above described procedure on your test environment? May you can figure out why BatchPatch isn’t working for Win 2016 servers without having an active internet connection.

Dennis

[doug]

Dennis – If you are still experiencing the 106G error, I would ask you to please follow the instructions that I gave you in my previous postings above. So far you have not actually tried any of those suggestions, so I cannot really make a new suggestion if you are not willing to try the existing suggestions.

-Doug

[dennis]

Doug,

Just to make sure I didn’t missed anything in 106G error article I re-read it and there is still no solution provided to me.

Option 0: done, didn’t help

Option 1: We don’t have any driver updates in our repository

Option 2: If I create that rule as described, 0 updates match that filter/policy

Option 3: done, didn’t help

Option 4: same as Option 1, no driver updates in our repository. Besides it did not even work with a fresh WSUS infrastructure with only 20 updates released (only Office and Win)

So what else to do? I’m at the end of my possibilities to get Batchpatch working. Let me know what kind of data / log you need and I will provide them to you. I really need to get this working.

Dennis

[doug]

From my posting above in this same thread:

“Then I would suggest that you decline all of the ~20 updates that you approved on the new WSUS. Wait a few minutes after doing that because all SQL activity on the WSUS server has to complete/stop before the declination will be complete in the WSUS database even though the WSUS GUI will appear to indicate that the declination is instantaneous. Once the declination is *truly* complete and all SQL activity on the WSUS stops (you could wait a little while like 20 minutes just to be absolutely sure), then you can do a new check for available updates in BP. At this point the search should complete and there should be no updates found because there are none approved. Then starting with one update at at a time you can approve just the one update. Then wait a couple of minutes until all SQL activity stops on the WSUS, and then test BP again. The goal is to find which update is causing the problem by approving just one update at a time and testing the BP check for available updates in between each approval. But it’s also important to wait until SQL activity stops after initiating the approval (or a declination) because otherwise you will get misleading results if you initiate the BP check for available updates too soon after making the approval or declination.

Now, since you did not receive the exact same HRESULT that is described in the other Error 106G article, I cannot guarantee that the problem will be fixed by finding a problematic update and declining it. However, at the same time, we have not yet experienced or reproduced this problem here. I understand that it seems to be affected by using the German time and region settings, so it is something that we can try to reproduce and test here, but it will take some time. Also, it’s important to understand that with 106G, it’s not likely something that we can fix/change/modify in our code, because the problem is that the search result that the WSUS server sends back to the client during the update search is what has problems, not the BP code. The key is to find out what is causing the WSUS to return unusable results, and in the past the issue seemed to always come down to a particular problematic update on the WSUS. And in your case there seems to also be a relationship to the German time/region setting.”

[dennis]

Doug,

As recommended by you I declined all previously approved updates and waited for a whole day to recheck for pendable updates on the client through Batchpatch. Even with 0 updates approved to the client I’m getting an error message in Batchpatch.

23 November 2017 – 09:04:18> Windows Update: Error -102: Failed to execute the search.

23 November 2017 – 09:04:03> Windows Update: Executing BatchPatchRemoteAgent.exe…

23 November 2017 – 09:04:03> Windows Update: Attempting to initiate Windows Update (Action: Search for updates: ‘SoftwareOnly’ | Server selection: Default / Managed) …

23 November 2017 – 09:04:03> Windows Update: Establishing connection…

23 November 2017 – 09:04:03> Windows Update: Initializing…

23 November 2017 – 09:04:03> Windows Update: Queued… (Check for available updates)

Just to clarify once more. The problem to check Win 2016 servers with Batchpatch seems not be related to the installed language. The only reason it worked for our US servers is because they do have access to the internet. So Batchpatch was able to return an update result from Microsofts public WSUS servers. As soon as we enable our EMEA servers to access those public WSUS server Batchpatch will return a result of pending updates.

As this is an absolute no-go Batchpatch seems to have trouble to report the result delivered by an internal WSUS server when external WSUS servers are not accessible.

Dennis

[doug]

Dennis – The entire posting about declining the updates on the WSUS server was for troubleshooting/resolving the 106G error that you originally posted about and that is the main topic for this entire thread. However, now it appears that you are instead talking about the completely unrelated -102 error and not the 106G error. When you first mentioned the -102 error last week I asked you for the HRESULT value, but you never gave it to me and you never again mentioned -102. All subsequent references in both your postings and my postings were to the “106G error.”

In any case, the -102 error should be simple to resolve because it has nothing to do with a problematic update on the WSUS and nothing to do with the complicated 106G error. However, in order to understand why the -102 is occurring we need to know the HRESULT, so once again I shall ask you to please provide me with the HRESULT value for the -102 error. You can find this in the ‘Remote Agent Log’ column as well as in the BatchPatch.log file on the target computer in the BatchPatch remote working directory, which by default is C:Program FilesBatchPatch. It will say:

-102: Failed to execute the search. HRESULT: -XXXXXXXXXX

-Doug

[dennis]

-102: Failed to execute the search. HRESULT: -2147012721

[doug]

Thanks. This is the same error that was in your WindowsUpdate.log that we discussed last week. It’s a Windows Update error, not a BatchPatch error.

0x80072F8F -2147012721 ERROR_INTERNET_SECURE_FAILURE   ErrorClockWrong

One or more errors were found in the Secure Sockets

Layer (SSL) certificate sent by the server.

Googling I found the following link, which has some potentially helpful information:

https://social.technet.microsoft.com/Forums/windows/en-US/ef49580b-8d8f-4bae-9d73-6bf32ba4d463/windows-update-not-running-in-windows-2012-r2-0x80072f8f?forum=winserver8gen

If you are not able to resolve it based on the suggestions in that link then might need to keep googling 0x80072F8F and see what other things you can find that help.

You are the only BatchPatch user who has ever reported this error, so it must be something specific to your environment that is causing it.

I would suggest starting by making sure that your BIOS clock and your Windows time in the OS are accurate. If they are off too much from real-time or from your WSUS, that could be the problem. Also make sure that the certificate installed on your WSUS does not have any issues or timestamp problems etc.

[dennis]

Doug,

I guess I’m aware of the root cause for the above error in our environment. As our servers don’t have internet access enabled by default they are hitting some special firewall rules with SSL inspection, so that will probably cause the error above.

Nevertheless that shouldn’t happen at all because the servers are configured to use local WSUS but Batchpatch seems to bypass that setting. Even if Batchpatch is configured to use “Default / Managed” in settings.

Speaking about our servers that have internet servers Batchpatch works in a way and returns the result from public WSUS server. So if I look up for updates to install on the local server I get those updates as available:

Microsoft SQL Server 2014 SP2 Cumulative Update (CU) 1 KB3178925.

Definition Update for Windows Defender – KB2267602 (Definition 1.257.1036.0).

If I use Batchpatch to look for available updates on the exact same server I get those updates:

1> 2017-11 Cumulative Update for Windows Server 2016 for x64-based Systems (KB4051033) (1189 MB) (2017-11-27) – Updates

(Type-SoftwareUpdate | Downloaded-FALSE | RebootRequired-MAYBE)

http://support.microsoft.com/kb/4051033

2> Definition Update for Windows Defender – KB2267602 (Definition 1.257.1076.0) (195 MB) (2017-11-28) – Definition Updates

(Type-SoftwareUpdate | Downloaded-FALSE | RebootRequired-FALSE)

http://support.microsoft.com/kb/2267602

So that’s not the same – how can that be?

Dennis

[doug]

Based on what you are describing it sounds like you might have “dual-scan” enabled on these computers. Microsoft introduced new behavior to the Windows Update Agent (WUA) recently that can cause computers to scan against Windows Update or Microsoft Update instead of your local WSUS, and it sounds like you might be affected by it.

We have two blog postings about this topic that explain what it is, how to tell if it’s enabled, and how to disable it. Please read through them very carefully and thoroughly. Let me know what you find.

“Dual Scan” Difficulties with Windows Update on Windows 10 versions 1607 ‘Anniversary update’ and 1703 ‘Creators update’

Deciphering “Dual Scan” Behavior in Windows 10

---

Other possible reasons for why different updates might be displayed when checking for updates directly on the computer through the Windows Update control panel vs checking for udpates through BatchPatch are explained in question 2 in the FAQ

-Doug

[dennis]

Doug,

Thank you for providing those helpful articles. I was going ahead and changing some GPO settings as described in your articels. One of the settings was to disable the update search againg offical Microsoft update server.

I also made sure that the local WSUS is set as primary update source.

Anyway if I trigger the update search through Batchpatch I’m receiving the following error now:

::Begin online search – Server Selection: Default

-102: Failed to execute the search. HRESULT: -2145103860

After converting that error to 8024500C and googeling for it it seems like this error is related to disabling the external update search.

As we have set an internal WSUS server in our GPO and have Batchpatch set to “Default / Managed” as WSUS source I cannot understand why Batchpatch still bypasses this policy and tries to connect to an external WSUS server.

Dennis

[doug]

Dennis – If ‘dual-scan’ is enabled, it really has nothing to do with BatchPatch. BatchPatch doesn’t bypass your local WSUS– it’s a Windows OS issue. Windows is the culprit for this behavior.

Those articles that I linked to previously explain exactly how to determine if dual-scan is enabled and exactly how to disable dual-scan. It is very specific, and the instructions must be followed carefully and exactly. One of the articles even explains the cause of the error that you mentioned (-102: Failed to execute the search. HRESULT: -2145103860) in the ‘Additional Notes’ section. This error is caused by enabling a particular GPO, but that GPO is *not* the solution to disabling dual scan, so it seems to me that you may not have followed the *exact* instructions in the links that I provided to you.

I would ask you again to *please* follow the instructions *exactly.*

You need first confirm if Dual Scan is enabled or not. The process for this is described in the section titled:

‘How To Confirm If “Dual Scan” Is Or Is Not Enabled’ which appears in the following article:

Deciphering “Dual Scan” Behavior in Windows 10

And then if it is enabled you must follow the instructions to disable Dual Scan under the section titled:

‘How to Disable “Dual Scan”‘ which appears in the following article:

“Dual Scan” Difficulties with Windows Update on Windows 10 versions 1607 ‘Anniversary update’ and 1703 ‘Creators update’

[dennis]

Doug,

As I said in my previous post your articles have been helpful. That meant I used the GPO settings to *disable* Dual Scan and also *verified* through Powershell that the internal WSUS is set as primary target.

If I could I would add screenshots to my posts but this seems not to be possible…

So we’re at the same point as before: Windows is *set* to use internal WSUS *only*. If I browse *locally* for updates, there are no attempts made to connect to an external WSUS. This was verified by checking the firewall logs. As soon as I try to look up for updates through Batchpatch I’m getting back the error message as above.

[doug]

I’ve sent you an email for further troubleshooting and to see screenshots etc.

[doug]

For the following error:

Windows Update: Error 1620: -106. Failure

Windows Update: -106G: Update search completed with errors: -2145123271

---

In the case where this error occurs when using a local WSUS (as opposed to using ‘Windows Update’ or ‘Microsoft Update’ public servers), one possible solution is described below:

The problem appears to be:

WARNING: The server returned HTTP status code ‘413 (0x19D)’ with text ‘Request Entity Too Large’.

WARNING: MapToSusHResult mapped Nws error 0x803d0000 to 0x80240439

The solution described at the following link suggests:

https://social.technet.microsoft.com/Forums/en-US/df4db9d0-9620-4af1-b514-6767951b2f18/http-413-request-entity-too-large-during-update-scan?forum=configmanagersecurity

After increasing IIS setting uploadReadAheadSize on WSUS server from 49152 to 491521 the missing updates (KB3213986, KB3214628) is installing properly on 1607 client.

Launch “Internet Information Services (IIS) Manager”

Expand the Server field

Expand Sites

Select the site you want to make the modification for. (WSUS Administration)

In the Features section, double click “Configuration Editor”

Under “Section” select: system.webServer -> serverRuntime

Modify the “uploadReadAheadSize” section (This value should be in Bytes)

Click Apply

Do an IIS Reset

[doug]

In the next version of BP we have modified the code so that BP is able to successfully ignore this particular error ( -2145123271 ) and continue, at least in certain instances. Release date TBD, but it should be not too far off. We are not sure which other “flavors” of -106G will be ignorable since we cannot reproduce all of them. However, we know for sure that some “flavors” of -106G cannot be ignored while others can be.

-Doug

[Author]

Posts