none
New systems can't update.

    Question

  • I have some new systems that are failing to selfupdate.

    Client Diag:

    WSUS Client Diagnostics Tool

    Checking Machine State
            Checking for admin rights to run tool . . . . . . . . . PASS
            Automatic Updates Service is running. . . . . . . . . . PASS
            Background Intelligent Transfer Service is running. . . PASS
            Wuaueng.dll version 7.1.6001.65 . . . . . . . . . . . . PASS
                    This version is WSUS 2.0

    Checking AU Settings
            AU Option is 4: Scheduled Install . . . . . . . . . . . PASS
                    Option is from Policy settings

    Checking Proxy Configuration
            Checking for winhttp local machine Proxy settings . . . PASS
                    Winhttp local machine access type
                            <Direct Connection>
                    Winhttp local machine Proxy. . . . . . . . . .  NONE
                    Winhttp local machine ProxyBypass. . . . . . .  NONE
            Checking User IE Proxy settings . . . . . . . . . . . . PASS
                    User IE Proxy. . . . . . . . . . . . . . . . .  NONE
                    User IE ProxyByPass. . . . . . . . . . . . . .  NONE
                    User IE AutoConfig URL Proxy . . . . . . . . .  NONE
                    User IE AutoDetect
                    AutoDetect not in use

    Checking Connection to WSUS/SUS Server
                    WUServer =
    https://FQDN:8531
                    WUStatusServer = https://FQDN:8531
            UseWuServer is enabled. . . . . . . . . . . . . . . . . PASS
            Connection to server. . . . . . . . . . . . . . . . . . PASS

    WinHttpDownloadFileToMemory(szURLDest, NULL, 0, NULL, NULL, NULL, &downloadBuffer) failed with hr=0x80072efd

    A connection with the server could not be established

    WindowsUpdate.log

    Service Main starts
    Using BatchFlushAge = 31976.
    Using SamplingValue = 870.
    Successfully loaded event namespace dictionary.
    Successfully loaded client event namespace descriptor.
    Successfully initialized local event logger. Events will be logged at C:\WINDOWS\SoftwareDistribution\ReportingEvents.log.
    Successfully initialized NT event logger.
    Successfully initialized event uploader 0.
    Successfully initialized event uploader 1.
    WU client with version 5.4.3790.5512 successfully initialized
    Service status is now SERVICE_RUNNING
    Successfully opened event cache file at C:\WINDOWS\SoftwareDistribution\EventCache\{EAD91509-6755-4774-B111-C51B18938009}.bin for reading.
    Trying to make out of proc datastore active
    Out of proc datastore is now active
    PT: Using serverID {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}
    Failed to obtain cached cookie with hr = 80248008.
    Failed to upload events with hr = 80248008.
    Client Call Recorder finished delayed initialization
    Setting next AU detection timeout to 2008-05-31 00:34:54
    Setting AU scheduled install time to 2008-05-31 07:00:00
    AU finished delayed initialization
    AU received event of 1
    WU client succeeds CClientCallRecorder::BeginFindUpdates from AutomaticUpdates with call id {25BFA706-D583-471B-ACBE-EE45DA038918}
    Triggering AU detection through DetectNow api
    AU received event of 1
    WU client executing call {25BFA706-D583-471B-ACBE-EE45DA038918} of type Search Call
    Send failed with hr = 80072efd.
    SendRequest failed with hr = 80072efd. Proxy List used: <(null)> Bypass List used : <(null)>
    Send failed with hr = 80072efd.
    SendRequest failed with hr = 80072efd. Proxy List used: <(null)> Bypass List used : <(null)>
    Send failed with hr = 80072efd.
    SendRequest failed with hr = 80072efd. Proxy List used: <(null)> Bypass List used : <(null)>
    Send failed with hr = 80072efd.
    SendRequest failed with hr = 80072efd. Proxy List used: <(null)> Bypass List used : <(null)>
    DownloadFileInternal failed for
    https://FQDN:8531/SelfUpdate/wuident.cab: error 0x80072efd
    IsUpdateRequired failed with error 0x80072efd
    OS Version = 5.1.2600.3.0.65792
    Computer Brand = INTEL_
    Computer Model = DQ965GF_
    Bios Revision = CO96510J.86A.5953.2007.0730.2059
    Bios Name = Default System BIOS
    Bios Release Date = 2007-07-30T00:00:00
    Locale ID = 1033
    ClientVersion: iuengine.dll = 5.4.3790.5512
    ClientVersion: wuapi.dll = 5.4.3790.5512
    ClientVersion: wuauclt.exe = 5.4.3790.5512
    ClientVersion: wuauclt1.exe = 5.4.3790.5512
    ClientVersion: wuaucpl.cpl = 5.4.3790.5512
    ClientVersion: wuaueng.dll = 5.4.3790.5512
    ClientVersion: wuaueng1.dll = 5.4.3790.5512
    ClientVersion: wuauserv.dll = 5.4.3790.5512
    ClientVersion: wucltui.dll = 5.4.3790.5512
    PT: Using serverID {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}
    WU client failed Searching for update with error 0x80248008
    Search Callback Failed, hr is 0x80248008
    Setting next AU detection timeout to 2008-05-31 04:08:12
    Setting AU scheduled install time to 2008-05-31 07:00:00
    WU client calls back to search call AutomaticUpdates with code Call failed and error 0x80248008
    WU client completed and deleted call {25BFA706-D583-471B-ACBE-EE45DA038918}
    REPORT EVENT: {5B1BEDFD-ACC9-4736-86D8-DA543C819528} 7 2008-05-30 20:34:59-0400 1 148 101 {D67661EB-2423-451D-BF5D-13199E37DF28} 0 80072efd SelfUpdate Failure Software Synchronization Error: Agent failed detecting with reason: 0x80072efd
    REPORT EVENT: {10F33ADC-6380-42CF-8AD9-6691BA6E1CD8} 8 2008-05-30 20:34:59-0400 1 148 101 {00000000-0000-0000-0000-000000000000} 0 80248008 AutomaticUpdates Failure Software Synchronization Error: Agent failed detecting with reason: 0x80248008
    Created new event cache file at C:\WINDOWS\SoftwareDistribution\EventCache\{5E9612DA-F6BD-44CA-ACB1-0B198639D3B9}.bin for writing.
    Reopened existing event cache file at C:\WINDOWS\SoftwareDistribution\EventCache\{5C170945-955F-4AE9-BF91-0341D0B8C5C2}.bin for writing.
    start delayed initialization of WU client

    I think it is just the self update tree since existing machines are continuing to update normally.  If I copy that failing URL into IE6 on the same client, I am successfully able to download and open the .cab file.

    Any insight would be great.
    Joe

    Saturday, May 31, 2008 12:52 AM

Answers

  • Hi Joe,

    I found that your client communicate with WSUS server using https://FQDN:8531

    Please verify that you have properly configured the ssl setting on WSUS server and client, see the following information:


    You can use the Secure Sockets Layer (SSL) protocol to secure your WSUS deployment. WSUS uses SSL to allow client computers and downstream WSUS servers to authenticate the WSUS server. WSUS also uses SSL to encrypt the metadata (the information about the updates) passed between clients and downstream WSUS servers. Note that WSUS uses SSL only for metadata, not for content (the update files themselves). This is also the way Microsoft Update distributes updates.

    Configuring SSL on the WSUS Server
    The most important thing to remember when configuring the WSUS server to use SSL is that WSUS requires two ports in this configuration: one for encrypted metadata using HTTPS and one for HTTP. When you configure IIS to use SSL, keep the following points in mind:

    You cannot set up the entire WSUS Web site to require SSL. This would mean that all traffic to the WSUS site would have to be encrypted, but WSUS encrypts only update metadata. If a client computer or another WSUS server attempts to get update files from WSUS on the HTTPS port, the transfer will fail.


    To keep the WSUS Web site as secure as possible, require SSL only for the following virtual roots:


    SimpleAuthWebService


    DSSAuthWebService


    ServerSyncWebService


    ApiRemoting30


    ClientWebService


    To keep WSUS functioning, you should not require SSL for the following virtual roots:


    Content


    Inventory


    ReportingWebService


    SelfUpdate


    The certificate on downstream WSUS servers has to be imported into either the local computer's Trusted Root CA store or the Windows Server Update Service's Trusted Root CA store. If the certificate is imported only to the Local User's Trusted Root CA store, the downstream WSUS server will fail server authentication on the upstream server.


    Configuring SSL on client computers
    There are two important considerations when configuring client computers:

    You must include a URL for a secure port on which the WSUS server is listening. Because you cannot require SSL on the server, the only way to ensure that client computers use a secure channel is to make sure they use a URL that specifies HTTPS. If you are using any port other than 443 for SSL, you must include that port in the URL.

    For more information about how to point client computers to the WSUS server, see Set Up a Client Computer.


    The certificate on a client computer has to be imported into either the Local Computer's Trusted Root CA store or Automatic Update Service's Trusted Root CA store. If the certificate is imported only to the Local User's Trusted Root CA store, Automatic Updates will fail server authentication.


    --------------------
    Regards,
    Eric Zhang




    Wednesday, June 4, 2008 12:54 PM
    Moderator

All replies

  • Then again maybe something more serious is wrong.  Same error if I run ClientDiag on the WSUS (3.0 SP1) server.
    Saturday, May 31, 2008 12:57 AM
  • Hi Joe,

    Please check the IIS for the virtual directory "selfupdate" under WSUS Adminitrator website.

    If it did not exists, please manually create the vitural directory(the default local path should be C:\Program Files\Update Services\Selfupdate) in IIS and giving it anonymous access.

    Then restart the Windows Update Service.

    --------------------
    Regards,
    Eric Zhang

    Tuesday, June 3, 2008 6:16 AM
    Moderator
  • Joe.Sanders said:

    If I copy that failing URL into IE6 on the same client, I am successfully able to download and open the .cab file.



    The SelfUpdate virtual directory already exists and anonymous authentication is enabled.
    Tuesday, June 3, 2008 11:43 AM
  • Hi Joe,

    I found that your client communicate with WSUS server using https://FQDN:8531

    Please verify that you have properly configured the ssl setting on WSUS server and client, see the following information:


    You can use the Secure Sockets Layer (SSL) protocol to secure your WSUS deployment. WSUS uses SSL to allow client computers and downstream WSUS servers to authenticate the WSUS server. WSUS also uses SSL to encrypt the metadata (the information about the updates) passed between clients and downstream WSUS servers. Note that WSUS uses SSL only for metadata, not for content (the update files themselves). This is also the way Microsoft Update distributes updates.

    Configuring SSL on the WSUS Server
    The most important thing to remember when configuring the WSUS server to use SSL is that WSUS requires two ports in this configuration: one for encrypted metadata using HTTPS and one for HTTP. When you configure IIS to use SSL, keep the following points in mind:

    You cannot set up the entire WSUS Web site to require SSL. This would mean that all traffic to the WSUS site would have to be encrypted, but WSUS encrypts only update metadata. If a client computer or another WSUS server attempts to get update files from WSUS on the HTTPS port, the transfer will fail.


    To keep the WSUS Web site as secure as possible, require SSL only for the following virtual roots:


    SimpleAuthWebService


    DSSAuthWebService


    ServerSyncWebService


    ApiRemoting30


    ClientWebService


    To keep WSUS functioning, you should not require SSL for the following virtual roots:


    Content


    Inventory


    ReportingWebService


    SelfUpdate


    The certificate on downstream WSUS servers has to be imported into either the local computer's Trusted Root CA store or the Windows Server Update Service's Trusted Root CA store. If the certificate is imported only to the Local User's Trusted Root CA store, the downstream WSUS server will fail server authentication on the upstream server.


    Configuring SSL on client computers
    There are two important considerations when configuring client computers:

    You must include a URL for a secure port on which the WSUS server is listening. Because you cannot require SSL on the server, the only way to ensure that client computers use a secure channel is to make sure they use a URL that specifies HTTPS. If you are using any port other than 443 for SSL, you must include that port in the URL.

    For more information about how to point client computers to the WSUS server, see Set Up a Client Computer.


    The certificate on a client computer has to be imported into either the Local Computer's Trusted Root CA store or Automatic Update Service's Trusted Root CA store. If the certificate is imported only to the Local User's Trusted Root CA store, Automatic Updates will fail server authentication.


    --------------------
    Regards,
    Eric Zhang




    Wednesday, June 4, 2008 12:54 PM
    Moderator
  • Hi,

    As this thread has been quiet for a while, we assume that the issue has been resolved. At this time, we will mark it as ‘Answered’ as the previous steps should be helpful for many similar scenarios.

    If the issue still persists and you want to return to this question, please reply this post directly so we will be notified to follow it up. You can also choose to unmark the answer as you wish.

    In addition, we’d love to hear your feedback about the solution. By sharing your experience you can help other community members facing similar problems.

    Thanks!
    --------------------
    Regards,
    Eric Zhang

    Wednesday, June 11, 2008 7:48 AM
    Moderator