none
Strange twist on update error 0x80072EFD

    Question

  • Some background:

    I have a WSUS server at a remote location running on 2008R2. This WSUS server has been working perfectly until 2/6/13. Doing research on this has revealed this is typically a network connection issue as the error means ERROR_INTERNET_CANNOT_CONNECT.

    However, this is not the case. If I open IE and try to browse to <servername>.<domain>.local from a client workstation I get the standard IIS7 welcome screen. I have also tried <servername>.<domain>.local/selfupdate/iuident.cab and I am able to download the iuident.cab file. So obviously the clients can reach the wsus machine.

    Although I was sure it would not work since my DNS is working properly, I tried changing from the FQDN to the IP address in the Group Policy settings. As I suspected, this did not resolve the issue.

    I have followed the steps in KB836941 with no success

    Here is a snippet from the windows update log:

    2013-03-28 16:56:26:921  868 fc8 AU Triggering Online detection (interactive)
    2013-03-28 16:56:26:937  868 ff8 AU #############
    2013-03-28 16:56:26:937  868 ff8 AU ## START ##  AU: Search for updates
    2013-03-28 16:56:26:937  868 ff8 AU #########
    2013-03-28 16:56:26:937  868 ff8 AU <<## SUBMITTED ## AU: Search for updates [CallId = {91483FC1-DB3B-4B8F-BFCC-8B7CFBF73472}]
    2013-03-28 16:56:26:937  868 a9c Agent *************
    2013-03-28 16:56:26:937  868 a9c Agent ** START **  Agent: Finding updates [CallerId = AutomaticUpdates]
    2013-03-28 16:56:26:937  868 a9c Agent *********
    2013-03-28 16:56:26:937  868 a9c Agent   * Online = Yes; Ignore download priority = No
    2013-03-28 16:56:26:937  868 a9c Agent   * Criteria = "IsInstalled=0 and DeploymentAction='Installation' or IsPresent=1 and DeploymentAction='Uninstallation' or IsInstalled=1 and DeploymentAction='Installation' and RebootRequired=1 or IsInstalled=0 and DeploymentAction='Uninstallation' and RebootRequired=1"
    2013-03-28 16:56:26:937  868 a9c Agent   * ServiceID = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7} Managed
    2013-03-28 16:56:26:937  868 a9c Agent   * Search Scope = {Machine}
    2013-03-28 16:56:26:937  868 a9c Setup Checking for agent SelfUpdate
    2013-03-28 16:56:26:937  868 a9c Setup Client version: Core: 7.6.7600.256  Aux: 7.6.7600.256
    2013-03-28 16:56:26:937  868 a9c Misc Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\wuident.cab:
    2013-03-28 16:56:26:953  868 a9c Misc  Microsoft signed: Yes
    2013-03-28 16:56:30:218  868 a9c Misc WARNING: Send failed with hr = 80072efd.
    2013-03-28 16:56:30:218  868 a9c Misc WARNING: SendRequest failed with hr = 80072efd. Proxy List used: <(null)> Bypass List used : <(null)> Auth Schemes used : <>
    2013-03-28 16:56:30:218  868 a9c Misc WARNING: WinHttp: SendRequestUsingProxy failed for <http://10.3.201.19:8530/selfupdate/wuident.cab>. error 0x80072efd
    2013-03-28 16:56:30:218  868 a9c Misc WARNING: WinHttp: SendRequestToServerForFileInformation MakeRequest failed. error 0x80072efd
    2013-03-28 16:56:30:218  868 a9c Misc WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x80072efd
    2013-03-28 16:56:30:218  868 a9c Misc WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x80072efd
    2013-03-28 16:56:33:499  868 a9c Misc WARNING: Send failed with hr = 80072efd.
    2013-03-28 16:56:33:499  868 a9c Misc WARNING: SendRequest failed with hr = 80072efd. Proxy List used: <(null)> Bypass List used : <(null)> Auth Schemes used : <>
    2013-03-28 16:56:33:499  868 a9c Misc WARNING: WinHttp: SendRequestUsingProxy failed for <http://10.3.201.19:8530/selfupdate/wuident.cab>. error 0x80072efd
    2013-03-28 16:56:33:499  868 a9c Misc WARNING: WinHttp: SendRequestToServerForFileInformation MakeRequest failed. error 0x80072efd
    2013-03-28 16:56:33:499  868 a9c Misc WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x80072efd
    2013-03-28 16:56:33:499  868 a9c Misc WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x80072efd
    2013-03-28 16:56:36:781  868 a9c Misc WARNING: Send failed with hr = 80072efd.
    2013-03-28 16:56:36:781  868 a9c Misc WARNING: SendRequest failed with hr = 80072efd. Proxy List used: <(null)> Bypass List used : <(null)> Auth Schemes used : <>
    2013-03-28 16:56:36:781  868 a9c Misc WARNING: WinHttp: SendRequestUsingProxy failed for <http://10.3.201.19:8530/selfupdate/wuident.cab>. error 0x80072efd
    2013-03-28 16:56:36:781  868 a9c Misc WARNING: WinHttp: SendRequestToServerForFileInformation MakeRequest failed. error 0x80072efd
    2013-03-28 16:56:36:781  868 a9c Misc WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x80072efd
    2013-03-28 16:56:36:781  868 a9c Misc WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x80072efd
    2013-03-28 16:56:40:062  868 a9c Misc WARNING: Send failed with hr = 80072efd.
    2013-03-28 16:56:40:062  868 a9c Misc WARNING: SendRequest failed with hr = 80072efd. Proxy List used: <(null)> Bypass List used : <(null)> Auth Schemes used : <>
    2013-03-28 16:56:40:062  868 a9c Misc WARNING: WinHttp: SendRequestUsingProxy failed for <http://10.3.201.19:8530/selfupdate/wuident.cab>. error 0x80072efd
    2013-03-28 16:56:40:062  868 a9c Misc WARNING: WinHttp: SendRequestToServerForFileInformation MakeRequest failed. error 0x80072efd
    2013-03-28 16:56:40:062  868 a9c Misc WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x80072efd
    2013-03-28 16:56:40:062  868 a9c Misc WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x80072efd
    2013-03-28 16:56:40:062  868 a9c Misc WARNING: DownloadFileInternal failed for http://10.3.201.19:8530/selfupdate/wuident.cab: error 0x80072efd
    2013-03-28 16:56:40:062  868 a9c Setup WARNING: SelfUpdate check failed to download package information, error = 0x80072EFD
    2013-03-28 16:56:40:062  868 a9c Setup FATAL: SelfUpdate check failed, err = 0x80072EFD
    2013-03-28 16:56:40:062  868 a9c Agent   * WARNING: Skipping scan, self-update check returned 0x80072EFD
    2013-03-28 16:56:40:062  868 a9c Agent   * WARNING: Exit code = 0x80072EFD
    2013-03-28 16:56:40:062  868 a9c Agent *********
    2013-03-28 16:56:40:062  868 a9c Agent **  END  **  Agent: Finding updates [CallerId = AutomaticUpdates]
    2013-03-28 16:56:40:062  868 a9c Agent *************
    2013-03-28 16:56:40:062  868 a9c Agent WARNING: WU client failed Searching for update with error 0x80072efd
    2013-03-28 16:56:40:062  868 a88 AU >>##  RESUMED  ## AU: Search for updates [CallId = {91483FC1-DB3B-4B8F-BFCC-8B7CFBF73472}]
    2013-03-28 16:56:40:062  868 a88 AU   # WARNING: Search callback failed, result = 0x80072EFD
    2013-03-28 16:56:40:062  868 a88 AU   # WARNING: Failed to find updates with error code 80072EFD
    2013-03-28 16:56:40:062  868 a88 AU #########
    2013-03-28 16:56:40:062  868 a88 AU ##  END  ##  AU: Search for updates [CallId = {91483FC1-DB3B-4B8F-BFCC-8B7CFBF73472}]
    2013-03-28 16:56:40:062  868 a88 AU #############
    2013-03-28 16:56:40:062  868 a88 AU Successfully wrote event for AU health state:0
    2013-03-28 16:56:40:062  868 a88 AU AU setting next detection timeout to 2013-03-29 04:56:40
    2013-03-28 16:56:40:062  868 a88 AU Successfully wrote event for AU health state:0
    2013-03-28 16:56:40:062  868 a88 AU Successfully wrote event for AU health state:0
    2013-03-28 16:56:45:062  868 a9c Report REPORT EVENT: {F7FA2FC9-6C4C-480B-83D2-E69E2E19C667} 2013-03-28 16:56:40:062-0700 1 148 101 {D67661EB-2423-451D-BF5D-13199E37DF28} 1 80072efd SelfUpdate Failure Software Synchronization Windows Update Client failed to detect with error 0x80072efd.
    2013-03-28 16:56:45:156  868 a9c Report CWERReporter::HandleEvents - WER report upload completed with status 0x8
    2013-03-28 16:56:45:156  868 a9c Report WER Report sent: 7.6.7600.256 0x80072efd D67661EB-2423-451D-BF5D-13199E37DF28 Scan 101 Managed
    2013-03-28 16:56:45:156  868 a9c Report CWERReporter finishing event handling. (00000000)

    I am really kind of lost at this point. I have other remote locations that are configured the same that are working perfectly, so that *should* rule out a parent GPO interfering with WSUS at this location.

    Any help with this is greatly appreciated.

    Thanks,

    Michael

    jeudi 28 mars 2013 23:59

Réponses

  • There is no rhyme or reason as to why the port in IIS would change. As previously stated, this was a healthy and fully functioning WSUS environment. Then suddenly it broke due to the port change in IIS. Why or how this happened no one knows.

    After resetting the port in IIS to 8530 and opening a new connection to WSUS in the management console, everything is now working again and all but 2 of my clients have reported in and have 100% update rate.

    I am going to mark this as the answer since this is what solved the problem.

    It would be nice to know at some point in the future how or why IIS suddenly changed ports. The only thing I can think of is an update of some sort or another that might have reset IIS to default settings, but after spending several hours combing through the event logs and update logs I could not find anything.

    Michael

    • Marqué comme réponse Radius118 vendredi 5 avril 2013 16:51
    vendredi 5 avril 2013 16:51

Toutes les réponses

  •  After doing some more digging, it appears that the issue is with port 8530. If I remove that port number from the GPO, clients can then contact the WSUS server and check for updates. However, when trying to download the install the updates, the clients end up with error 80240016 and windows updates thinks the machine is installing other updates. If I continue down this path the machine basically gets "stuck" in an update loop.

     So it looks like I need to find out just how and why port 8530 is not working on my internal network. Which doesn't make any sense to me as I have nothing - that I am aware of - that should be interfering with port 8530.


    • Modifié Radius118 vendredi 29 mars 2013 17:41
    vendredi 29 mars 2013 17:40
  • Ok I am really pulling my hair out now. I cannot for the life of me see why my clients cannot access WSUS on port 8530 but they can on port 80.

    I could really use some help with this one. I have the feeling I am overlooking something obvious but I cannot see it.

    Thanks,

    Michael

    vendredi 29 mars 2013 21:57
  • Ok I am really pulling my hair out now. I cannot for the life of me see why my clients cannot access WSUS on port 8530 but they can on port 80.

    I could really use some help with this one. I have the feeling I am overlooking something obvious but I cannot see it.

    You can check the port on your WSUS admin console or the IIS console to see whether your WSUS is listening on port 80 or 8530.From your descriptions,it seems that your WSUS was listening on port 80.

    If you didn't set the correct port in your GPO,then you clients will never connect to your WSUS.That may become the root cause of why you got a network connection issue.

    Regards,

    Clarence

    TechNet Subscriber Support

    If you are TechNet Subscription user and have any feedback on our support quality, please send your feedback here.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    lundi 1 avril 2013 02:02
    Modérateur
  • You can check the port on your WSUS admin console or the IIS console to see whether your WSUS is listening on port 80 or 8530.From your descriptions,it seems that your WSUS was listening on port 80.

    If you didn't set the correct port in your GPO,then you clients will never connect to your WSUS.That may become the root cause of why you got a network connection issue.

     Yes I checked IIS console and the bindings to find that WSUS appeared to be listening on port 80. I added port 8530 as a binding but things are still not working correctly. The clients seem to be able to update now, but the WSUS administrator console cannot connect unless I open a new connection to the server at port 8530.

     Most troubling and the real issue here is *why* everything was working perfectly up until 02/06/13 and then suddenly broke. How would the port assignment in IIS change? No one is on that server except for me and I certainly did not change it.

    Michael



    • Modifié Radius118 lundi 1 avril 2013 16:07
    lundi 1 avril 2013 15:49
  • It is wierd.If you didn't know what has been changed before,then i suggest you have a reinstallation of WSUS without uninstalling the DB,Log file and update files.And then,install a new WSUS with the keeping db and update file to see whether it works.

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    jeudi 4 avril 2013 01:27
    Modérateur
  • There is no rhyme or reason as to why the port in IIS would change. As previously stated, this was a healthy and fully functioning WSUS environment. Then suddenly it broke due to the port change in IIS. Why or how this happened no one knows.

    After resetting the port in IIS to 8530 and opening a new connection to WSUS in the management console, everything is now working again and all but 2 of my clients have reported in and have 100% update rate.

    I am going to mark this as the answer since this is what solved the problem.

    It would be nice to know at some point in the future how or why IIS suddenly changed ports. The only thing I can think of is an update of some sort or another that might have reset IIS to default settings, but after spending several hours combing through the event logs and update logs I could not find anything.

    Michael

    • Marqué comme réponse Radius118 vendredi 5 avril 2013 16:51
    vendredi 5 avril 2013 16:51
  • There is no rhyme or reason as to why the port in IIS would change. As previously stated, this was a healthy and fully functioning WSUS environment. Then suddenly it broke due to the port change in IIS. Why or how this happened no one knows.

    After resetting the port in IIS to 8530 and opening a new connection to WSUS in the management console, everything is now working again and all but 2 of my clients have reported in and have 100% update rate.

    It would be nice to know at some point in the future how or why IIS suddenly changed ports. The only thing I can think of is an update of some sort or another that might have reset IIS to default settings...

    This statement has a big red flag in it... there's an implication here that the port of the DEFAULT WEB SITE was changed from port 80 to port 8530 in order to publish WSUS on port 8530. If that was done... that's a problem for sure. The Default Web Site should be running on port 80. WSUS uses resources from port 80, even when installed to port 8530.

    If it's desired to have WSUS running on port 8530, but it was originally installed to port 80, the correct procedure is to Uninstall WSUS (keeping the database, logs, and content), and then Reinstall WSUS, selecting port 8530 as the installation target.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2013)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    mercredi 29 mai 2013 15:45
    Modérateur
  • This statement has a big red flag in it... there's an implication here that the port of the DEFAULT WEB SITE was changed from port 80 to port 8530 in order to publish WSUS on port 8530. If that was done... that's a problem for sure. The Default Web Site should be running on port 80. WSUS uses resources from port 80, even when installed to port 8530.

    If it's desired to have WSUS running on port 8530, but it was originally installed to port 80, the correct procedure is to Uninstall WSUS (keeping the database, logs, and content), and then Reinstall WSUS, selecting port 8530 as the installation target.


     Hello Lawrence,

    I don't know what to say. I installed WSUS on that server with default settings, set up the GPO and WSUS was working perfectly for over 6 months. Then it stopped working. The port in IIS changed from 8530 to port 80. Once I set it back to port 8530 everything started working again and it's worked fine since. The mystery to me is how the port got changed. There is no one else in my organization who has access to the administrative functions of this server but myself.

    Michael

    mercredi 29 mai 2013 17:11