0

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

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
"WUServer"="http://kanwsus2k16:8530"
"WUStatusServer"="http://kanwsus2k16:8530"
"DoNotConnectToWindowsUpdateInternetLocations"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU]
"UseWUServer"=dword:00000001

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
Matt
  • 690
  • 6
  • 26
  • 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! – Am_I_Helpful May 07 '18 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 07 '18 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 09 '18 at 00:19

3 Answers3

0

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.

C C
  • 56
  • 4
0

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.

wrieedx
  • 700
  • 3
  • 11
  • 22
  • 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, :) – Am_I_Helpful May 08 '18 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 09 '18 at 00: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.) – Bill_Stewart Jul 11 '18 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 '18 at 00:15
0

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.

Am_I_Helpful
  • 499
  • 1
  • 6
  • 17
  • 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 08 '18 at 13:19
  • @Matt - It seems there has been some confusion. I asked the same, please check my comment on your question: https://serverfault.com/questions/911098/windows-update-bypassing-server-as-download-source/911269?noredirect=1#comment1179499_911098. Can you again share all the subkeys' and values present in the registry path `HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU`? – Am_I_Helpful May 08 '18 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 09 '18 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? – Am_I_Helpful May 09 '18 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 09 '18 at 17:55
  • Yes... I have restarted the server between tests just to be sure – Matt May 09 '18 at 17:56
  • Yes nslookup works. Like I said in the question telnet works – Matt May 09 '18 at 17:57
  • @Matt - Can you try deleting all these keys/subkeys under Windows Update registry, and try the way other answerer has suggested. That'd help you narrow down the problem. Also, you can keep a backup for the registry currently set. – Am_I_Helpful May 09 '18 at 18:05
  • @Matt - Also, can you share the output of the command `netsh winhttp show proxy` by running it in cmd/powershell? – Am_I_Helpful May 09 '18 at 18:07
  • Will do when I can – Matt May 09 '18 at 18:07