I have a Windows Server 2008 R2 SP1 machine that is isolated in a DMZ. Historically it has not had issues but everything works before it breaks. The port 8530 is open on the firewall appliance and I can telnet from the client to the server which proves the site is ready and open.

This machine is not attached to the domain so WSUS server is set in the registry. So under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate I have



The windowsupdate.log corroborates this. I would like to try and include only what is required to try and keep the post length down. The client reaches out to the server and see that it has X available updates. However it fails to download those. The log shows entries like this:

2018-05-07  11:05:19:960     668    47c DnldMgr BITS job {7835096F-E02C-4B66-AD0F-3D71EF17C73B} hit a transient error, updateId = {3FD57624-1808-41C7-979D-8606CA1229B6}.202, error = 0x80072EE2
... output truncated ....
2018-05-07  11:05:40:963     668    47c Misc    WARNING: SendRequest failed with hr = 80072ee2. Proxy List used: <(null)> Bypass List used : <(null)> Auth Schemes used : <>
2018-05-07  11:05:40:963     668    47c Misc    WARNING: WinHttp: SendRequestUsingProxy failed for <http://wsus.ds.download.windowsupdate.com/d/msdownload/update/software/secu/2018/04/windows6.1-kb4093118-x64-express_c1473ce4b149cf34239c364a9787030447e376ca.cab>. error 0x80072ee2

With regards to the SendRequestUsingProxy failed, that should fail. The server does not have access to Microsoft websites so it will be blocked from being able to go there. What I can't figure out is why it isnt getting the updates from the WSUS server directly. We do not use a proxy nor is one configured.

On the WSUS Server side of things I see that it get a download failed status for each of the updates. So in short the communication is there but the client is trying to download the updates from externally. It is a 2k16 server and reading the logs with Get-WindwosUpdateLog has not proven useful.

This is the only external server I have to the network so I do not have any comparison systems to know exactly where the system is.

In an attempt to testing connectivity to the server I try to browse to http://kanwsus2k16:8530/selfupdate/wuident.cab which is met with page cannot be displayed on the client server. (That link works fine on the internal network)

Why is my Windows Update client not honoring the WSUS path for updates and instead attempting to go externally for Microsoft?

Other things I have tried:

  • System Update Readiness Tool for Windows Server 2008 R2 x64 Edition
  • Clearing BITS Queue
  • Renaming SoftwareDistribution folder
  • Verified nothing is being blocked from the networking side going to WSUS server on port 8530
  • Added DoNotConnectToWindowsUpdateInternetLocations equal to 1 in HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate
  • Can you share the complete settings for keys located in the registry HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate (an image/screenshot would do)? I suspect some mis-configuration in this registry setting! May 7, 2018 at 17:05
  • @Am_I_Helpful There is only one other value that I forgot to mention I added to try and fix this. See the update. I added DoNotConnectToWindowsUpdateInternetLocations but the issue existed before that.
    – Matt
    May 7, 2018 at 19:20
  • Maybe changing the registry directly is a mistake in this case. There are to many registry entries to consider and the possibility of making a mistake is high (e.g. you missed an entry, a value was entered in wrong, etc). I think that you should try group policy. It is much simpler in that there are only two settings that you need to change, and easier to understand/audit.
    – wrieedx
    May 9, 2018 at 0:19

3 Answers 3


You've not set the needed registry to highlight that Windows Update will be downloaded through WSUS.

Please set the following registry at the path HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU:

Value name: UseWUServer
Value data: Set this value to 1 to configure Automatic Updates 
      to use a server that is running Software Update Services instead of Windows Update.
Registry Value Type: Reg_DWORD

Other things are in place. Please also pay attention to the points suggested by wrieedx in the other answer above, especially the point to manage such things using gpedit.msc, instead of the change in the registry.

  • I never showed any subkeys for what you asked (I guess that was not clear to me if you were asking). That value is already there which is corroborated by the presence of the WSUS server in the logs. Thanks for the help so far though.
    – Matt
    May 8, 2018 at 13:19
  • @Matt - It seems there has been some confusion. I asked the same, please check my comment on your question: serverfault.com/questions/911098/…. Can you again share all the subkeys' and values present in the registry path HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU? May 8, 2018 at 13:22
  • It's in the question. I updated it yesterday to show all keys and values . Is that not what you were asking for?
    – Matt
    May 9, 2018 at 17:46
  • @Matt - Now I see, OK. Can you confirm whether the Proxy has been configured anywhere in your external server? Also, what happens when you do nslookup kanwsus2k16? Does it resolve to the correct WSUS Server IP-Address? That error code simply means there is a network connectivity problem, which is more of a firewall issue. It's tough for me to believe if the telnet kanwsus2k16 8530 succeeds in your case! Can you also confirm whether the Windows Update Service is running or not? May 9, 2018 at 17:52
  • The network issue comes from the fact that the dmz has no access to Microsoft. I know dns is fine since the logs are pushed to wsus. If it downloaded updates from wsus directly I would be fine
    – Matt
    May 9, 2018 at 17:55

I don't think you should fiddle with the registry in this case. There are too many registry entries to think about and the possibility of making a mistake is relatively high. If I were you, I would use local policy instead.

I have a server that is in a similar situation to yours--located in a DMZ, not connected to a domain, and receiving updates from an internal WSUS server. This server receiving updates just fine. I am using local policy to configure the server's windows update settings, which I think is more desirable than changing registry settings directly.

Open gpedit.msc as an administrator on the command line.

Navigate to Computer Configuration/Administrative Templates/Windows Components/Windows Update

Change the following settings:

  • Configure Automatic Updates: ENABLED
    • Set to "Auto download and notify for install"
  • Specify Intranet Microsoft Update Service Location: ENABLED
  • (Optional) Allow Automatic Update Immediate Installation: DISABLED
  • (Optional) Enable Client-side Targeting: ENABLED
    • Specify the name of the computer group you want to place the server in

As far as firewall settings, make sure that port 8530 is open from the DMZ server to the WSUS server. Also, if you are using internal DNS to resolve the WSUS server name, make sure that that port 53 is open between the DMZ server and the internal DNS server.

  • Though your answer and explanation is pretty good, it is not helpful to OP since why the behaviour of going to Internet, despite WSUS is not explained. Still a good post though, :) May 8, 2018 at 12:36
  • @Am_I_Helpful The behavior of going to the Internet is strange. But if the above group policies are set, the client server shouldn't go to the internet by default. Anyhow, I think that the OP should give group policy a try.
    – wrieedx
    May 9, 2018 at 0:21
  • 1
    In the question it states the machine is not joined to a domain, so there's no GPO to edit. (Unless you mean running gpedit.msc, but that modifies the local policy and is not the same as a GPO.) Jul 11, 2018 at 20:50
  • Whoops. I accidentally used the term "group policy" in my answer. I'll switch that over to "local policy."
    – wrieedx
    Jul 12, 2018 at 0:15

I would use Local Group Policy to set everything and walk through the settings that @Redwizard000 provided at https://serverfault.com/a/940236/557131. It is talking about Server 2016, but the policies are available to be set in older operating systems. This fixed an identical problem for me. If nothing else, he provides some command line to see if this is your problem before you put the effort into changing local policy or the registry.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.