Fail to download eula file with error 0x80244019

Discussion in 'Update Services' started by Dave Wright, Oct 9, 2009.

  1. Dave Wright

    Dave Wright Guest

    I am getting several updates that are failing on my System Center
    Configuration Manager 2007 WSUS Server when the clients try to download the
    EULA.

    Most updates install just fine, but certain updates that require a EULA are
    failing on some machines, but not all.

    I've tried running WSUSUTIL /reset on the WSUS server, and I have verified
    that the files do NOT exist on the WSUS server. I am unsure why the WSUS
    isn't getting the EULA, when all other WSUS functionality is working
    perfectly.

    The EULA HAS been accepted in the System Center Console on the updates in
    question.

    Any ideas?

    Here is an excerpt from the log of one of the machines that is failing to
    install Windows Vista Service Pack 2:

    2009-10-09 03:00:09:955 1100 11b4 AU Forced install timer expired for
    scheduled install
    2009-10-09 03:00:09:955 1100 11b4 AU UpdateDownloadProperties: 0 download(s)
    are still in progress.
    2009-10-09 03:00:09:955 1100 11b4 AU Setting AU scheduled install time to
    2009-10-10 08:00:00
    2009-10-09 06:24:26:142 1100 11b4 AU #############
    2009-10-09 06:24:26:142 1100 11b4 AU ## START ## AU: Search for updates
    2009-10-09 06:24:26:142 1100 11b4 AU #########
    2009-10-09 06:24:26:142 1100 11b4 AU <<## SUBMITTED ## AU: Search for
    updates [CallId = {35DB8ACA-BA60-4988-9290-1D1ABC638377}]
    2009-10-09 06:24:26:142 1100 43240 Agent *************
    2009-10-09 06:24:26:142 1100 43240 Agent ** START ** Agent: Finding updates
    [CallerId = AutomaticUpdates]
    2009-10-09 06:24:26:142 1100 43240 Agent *********
    2009-10-09 06:24:26:142 1100 43240 Agent * Online = Yes; Ignore download
    priority = No
    2009-10-09 06:24:26:142 1100 43240 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"
    2009-10-09 06:24:26:142 1100 43240 Agent * ServiceID =
    {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}
    2009-10-09 06:24:26:142 1100 43240 Agent * Search Scope = {Machine}
    2009-10-09 06:24:26:142 1100 43240 Setup Checking for agent SelfUpdate
    2009-10-09 06:24:26:189 1100 43240 Setup Client version: Core: 7.2.6001.788
    Aux: 7.2.6001.788
    2009-10-09 06:24:26:189 1100 43240 Misc Validating signature for
    C:\Windows\SoftwareDistribution\SelfUpdate\wuident.cab:
    2009-10-09 06:24:26:204 1100 43240 Misc Microsoft signed: Yes
    2009-10-09 06:24:26:485 1100 43240 Misc Validating signature for
    C:\Windows\SoftwareDistribution\SelfUpdate\wuident.cab:
    2009-10-09 06:24:26:485 1100 43240 Misc Microsoft signed: Yes
    2009-10-09 06:24:26:485 1100 43240 Misc Validating signature for
    C:\Windows\SoftwareDistribution\SelfUpdate\wsus3setup.cab:
    2009-10-09 06:24:26:501 1100 43240 Misc Microsoft signed: Yes
    2009-10-09 06:24:26:501 1100 43240 Misc Validating signature for
    C:\Windows\SoftwareDistribution\SelfUpdate\wsus3setup.cab:
    2009-10-09 06:24:26:501 1100 43240 Misc Microsoft signed: Yes
    2009-10-09 06:24:26:579 1100 43240 Setup Determining whether a new setup
    handler needs to be downloaded
    2009-10-09 06:24:26:579 1100 43240 Setup SelfUpdate handler is not found.
    It will be downloaded
    2009-10-09 06:24:26:579 1100 43240 Setup Evaluating applicability of setup
    package "WUClient-SelfUpdate-ActiveX~31bf3856ad364e35~x86~~7.1.6001.65"
    2009-10-09 06:24:26:719 1100 43240 Setup Setup package
    "WUClient-SelfUpdate-ActiveX~31bf3856ad364e35~x86~~7.1.6001.65" is not
    applicable
    2009-10-09 06:24:26:719 1100 43240 Setup Evaluating applicability of setup
    package "WUClient-SelfUpdate-Aux-TopLevel~31bf3856ad364e35~x86~~7.1.6001.65"
    2009-10-09 06:24:26:735 1100 43240 Setup Setup package
    "WUClient-SelfUpdate-Aux-TopLevel~31bf3856ad364e35~x86~~7.1.6001.65" is not
    applicable
    2009-10-09 06:24:26:735 1100 43240 Setup Evaluating applicability of setup
    package "WUClient-SelfUpdate-Core-TopLevel~31bf3856ad364e35~x86~~7.1.6001.65"
    2009-10-09 06:24:26:766 1100 43240 Setup Setup package
    "WUClient-SelfUpdate-Core-TopLevel~31bf3856ad364e35~x86~~7.1.6001.65" is not
    applicable
    2009-10-09 06:24:26:766 1100 43240 Setup SelfUpdate check completed.
    SelfUpdate is NOT required.
    2009-10-09 06:24:32:070 1100 43240 PT +++++++++++ PT: Synchronizing server
    updates +++++++++++
    2009-10-09 06:24:32:070 1100 43240 PT + ServiceId =
    {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL =
    http://admsccmu2.na.admworld.com:80/ClientWebService/client.asmx
    2009-10-09 06:24:32:148 1100 43240 PT WARNING: Cached cookie has expired or
    new PID is available
    2009-10-09 06:24:32:148 1100 43240 PT Initializing simple targeting cookie,
    clientId = 8acf3711-c735-4e6c-88c9-1f58d2f04d09, target group = CORP, DNS
    name = 021_jbeals.na.admworld.com
    2009-10-09 06:24:32:148 1100 43240 PT Server URL =
    http://admsccmu2.na.admworld.com:80/SimpleAuthWebService/SimpleAuth.asmx
    2009-10-09 06:24:35:549 1100 43240 Agent WARNING: Failed to evaluate
    Installed rule, updateId = {87CFBD65-2BD8-434F-AE28-59E3A2018AF3}.1, hr =
    8004100E
    2009-10-09 06:24:35:549 1100 43240 Agent WARNING: Failed to evaluate
    Installable rule, updateId = {87CFBD65-2BD8-434F-AE28-59E3A2018AF3}.1, hr =
    8004100E
    2009-10-09 06:24:35:549 1100 43240 Agent WARNING: Failed to evaluate
    Installed rule, updateId = {017CD15C-7188-4057-BFA1-1933409CA0AE}.1, hr =
    8004100E
    2009-10-09 06:24:35:549 1100 43240 Agent WARNING: Failed to evaluate
    Installable rule, updateId = {017CD15C-7188-4057-BFA1-1933409CA0AE}.1, hr =
    8004100E
    2009-10-09 06:24:36:048 1100 43240 PT +++++++++++ PT: Synchronizing
    extended update info +++++++++++
    2009-10-09 06:24:36:048 1100 43240 PT + ServiceId =
    {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL =
    http://admsccmu2.na.admworld.com:80/ClientWebService/client.asmx
    2009-10-09 06:24:42:896 1100 43240 Misc WARNING: WinHttp:
    SendRequestToServerForFileInformation failed with 0x80190194
    2009-10-09 06:24:42:896 1100 43240 Misc WARNING: WinHttp:
    ShouldFileBeDownloaded failed with 0x80190194
    2009-10-09 06:24:42:896 1100 43240 Agent WARNING: Fail to download eula file
    http://admsccmu2.na.admworld.com/Content/B5/F0950B606E4C05BFF99B0410E80CE4C077454BB5.txt with error 0x80244019
    2009-10-09 06:24:42:912 1100 43240 Misc WARNING: WinHttp:
    SendRequestToServerForFileInformation failed with 0x80190194
    2009-10-09 06:24:42:912 1100 43240 Misc WARNING: WinHttp:
    ShouldFileBeDownloaded failed with 0x80190194
    2009-10-09 06:24:42:912 1100 43240 Agent WARNING: Fail to download eula file
    http://admsccmu2.na.admworld.com/Content/2C/85605E276A7D714B23CCE78FACE8F915F1B7242C.txt with error 0x80244019
    2009-10-09 06:24:46:359 1100 43240 Agent * Found 0 updates and 59
    categories in search; evaluated appl. rules of 837 out of 1281 deployed
    entities
    2009-10-09 06:24:46:406 1100 43240 Agent *********
    2009-10-09 06:24:46:406 1100 43240 Agent ** END ** Agent: Finding updates
    [CallerId = AutomaticUpdates]
    2009-10-09 06:24:46:406 1100 43240 Agent *************
    2009-10-09 06:24:46:406 1100 433b0 AU >>## RESUMED ## AU: Search for
    updates [CallId = {35DB8ACA-BA60-4988-9290-1D1ABC638377}]
    2009-10-09 06:24:46:406 1100 433b0 AU # 0 updates detected
    2009-10-09 06:24:46:406 1100 433b0 AU #########
    2009-10-09 06:24:46:406 1100 433b0 AU ## END ## AU: Search for updates
    [CallId = {35DB8ACA-BA60-4988-9290-1D1ABC638377}]
    2009-10-09 06:24:46:406 1100 433b0 AU #############
    2009-10-09 06:24:46:406 1100 433b0 AU AU setting next detection timeout to
    2009-10-09 21:16:19
    2009-10-09 06:24:46:406 1100 433b0 AU Setting AU scheduled install time to
    2009-10-10 08:00:00
    2009-10-09 06:24:51:414 1100 43240 Report REPORT EVENT:
    {B5DC3CA8-E877-4F9B-B8EB-78741D59AFF0} 2009-10-09
    06:24:46:406-0500 1 147 101 {00000000-0000-0000-0000-000000000000} 0 0 AutomaticUpdates Success Software
    Synchronization Windows Update Client successfully detected 0 updates.
    2009-10-09 06:24:51:414 1100 43240 Report REPORT EVENT:
    {C72D7063-53A8-47D4-8390-6EF451A88EDA} 2009-10-09
    06:24:46:406-0500 1 156 101 {00000000-0000-0000-0000-000000000000} 0 0 AutomaticUpdates Success Pre-Deployment Check Reporting client status.
    2009-10-09 09:07:03:602 2436 420c8 COMAPI -------------
    2009-10-09 09:07:03:602 2436 420c8 COMAPI -- START -- COMAPI: Search
    [ClientId = CcmExec]
    2009-10-09 09:07:03:602 2436 420c8 COMAPI ---------
    2009-10-09 09:07:03:617 2436 420c8 COMAPI <<-- SUBMITTED -- COMAPI: Search
    [ClientId = CcmExec]
    2009-10-09 09:07:03:617 1100 434d8 Agent *************
    2009-10-09 09:07:03:617 1100 434d8 Agent ** START ** Agent: Finding updates
    [CallerId = CcmExec]
    2009-10-09 09:07:03:617 1100 434d8 Agent *********
    2009-10-09 09:07:03:617 1100 434d8 Agent * Include potentially superseded
    updates
    2009-10-09 09:07:03:617 1100 434d8 Agent * Online = No; Ignore download
    priority = Yes
    2009-10-09 09:07:03:617 1100 434d8 Agent * Criteria = "UpdateID =
    'cad30b29-e5a2-42ed-bcdc-501208b47b91' AND DeploymentAction = *"
    2009-10-09 09:07:03:617 1100 434d8 Agent * ServiceID =
    {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}
    2009-10-09 09:07:03:617 1100 434d8 Agent * Search Scope = {Machine}
    2009-10-09 09:07:15:536 1100 434d8 Agent * Added update
    {CAD30B29-E5A2-42ED-BCDC-501208B47B91}.102 to search result
    2009-10-09 09:07:15:551 1100 434d8 Agent * Found 1 updates and 59
    categories in search; evaluated appl. rules of 130 out of 1281 deployed
    entities
    2009-10-09 09:07:15:614 1100 434d8 Agent *********
    2009-10-09 09:07:15:614 1100 434d8 Agent ** END ** Agent: Finding updates
    [CallerId = CcmExec]
    2009-10-09 09:07:15:614 1100 434d8 Agent *************
    2009-10-09 09:07:15:614 2436 42fa4 COMAPI >>-- RESUMED -- COMAPI: Search
    [ClientId = CcmExec]
    2009-10-09 09:07:15:645 2436 42fa4 COMAPI - Updates found = 1
    2009-10-09 09:07:15:645 2436 42fa4 COMAPI ---------
    2009-10-09 09:07:15:645 2436 42fa4 COMAPI -- END -- COMAPI: Search
    [ClientId = CcmExec]
    2009-10-09 09:07:15:645 2436 42fa4 COMAPI -------------
    2009-10-09 09:07:15:645 2436 43838 COMAPI WARNING: ISusInternal::GetEulaText
    failed, hr=80240033
    2009-10-09 09:07:15:739 1100 4372c DnldMgr *********** DnldMgr: Copy update
    to cache [UpdateId = {9170A993-E4A3-4211-A924-1E07060BF602}.102] ***********
    2009-10-09 09:07:30:325 1100 4372c Misc Validating signature for
    C:\Windows\SoftwareDistribution\Download\106c0484d7449cc4b70353c21d0c0d63e4ba66c3:
    2009-10-09 09:07:31:931 1100 4372c Misc Microsoft signed: Yes
    2009-10-09 09:07:33:866 1100 4372c AU Triggering Offline detection
    (non-interactive)
    2009-10-09 09:07:33:866 1100 11b4 AU #############
    2009-10-09 09:07:33:866 1100 11b4 AU ## START ## AU: Search for updates
    2009-10-09 09:07:33:866 1100 11b4 AU #########
    2009-10-09 09:07:33:881 1100 11b4 AU <<## SUBMITTED ## AU: Search for
    updates [CallId = {F6E728C7-EDA9-4DAE-B6A2-442B6558C554}]
    2009-10-09 09:07:33:881 1100 434d8 Agent *************
    2009-10-09 09:07:33:881 1100 434d8 Agent ** START ** Agent: Finding updates
    [CallerId = AutomaticUpdates]
    2009-10-09 09:07:33:881 1100 434d8 Agent *********
    2009-10-09 09:07:33:881 1100 434d8 Agent * Online = No; Ignore download
    priority = No
    2009-10-09 09:07:33:881 1100 434d8 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"
    2009-10-09 09:07:33:881 1100 434d8 Agent * ServiceID =
    {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}
    2009-10-09 09:07:33:881 1100 434d8 Agent * Search Scope = {Machine}
    2009-10-09 09:07:44:656 1100 434d8 Agent * Found 0 updates and 59
    categories in search; evaluated appl. rules of 118 out of 1281 deployed
    entities
    2009-10-09 09:07:44:703 1100 434d8 Agent *********
    2009-10-09 09:07:44:703 1100 434d8 Agent ** END ** Agent: Finding updates
    [CallerId = AutomaticUpdates]
    2009-10-09 09:07:44:703 1100 434d8 Agent *************
    2009-10-09 09:07:44:703 1100 43834 AU >>## RESUMED ## AU: Search for
    updates [CallId = {F6E728C7-EDA9-4DAE-B6A2-442B6558C554}]
    2009-10-09 09:07:44:703 1100 43834 AU # 0 updates detected
    2009-10-09 09:07:44:703 1100 43834 AU #########
    2009-10-09 09:07:44:703 1100 43834 AU ## END ## AU: Search for updates
    [CallId = {F6E728C7-EDA9-4DAE-B6A2-442B6558C554}]
    2009-10-09 09:07:44:703 1100 43834 AU #############
    2009-10-09 09:07:44:703 1100 43834 AU Setting AU scheduled install time to
    2009-10-10 08:00:00
    Dave Wright, Oct 9, 2009
    #1
    1. Advertising

  2. "Dave Wright" <> wrote in message
    news:...

    >I am getting several updates that are failing on my System Center
    > I've tried running WSUSUTIL /reset on the WSUS server


    So, probably the correct syntax for the command would be good. There is no
    forward slash on the CLI parameters for wsusutil.exe.

    Just run WSUSUTIL RESET


    > I am unsure why the WSUS isn't getting the EULA, when all other WSUS
    > functionality is working
    > perfectly.


    If a file download failed, it will be logged in the Application Event Log of
    the WSUS Server;
    it will also be logged in the WSUS SoftwareDistribution.log
    found in the folder %ProgramFiles%\Update Services\Logfiles

    HOWEVER -- the client would not be able to detect the availability of the
    update unless the EULA had been previously downloaded, and the update
    approved; so this is more likely a case of the file being *deleted*, rather
    than never downloaded.


    > The EULA HAS been accepted in the System Center Console on the updates in
    > question.


    Assuming that WSUS is actually the configured SUP for SCCM; the EULA would
    have had to physically exist in order to have been accepted; so here we also
    have confirmation that the file was likely deleted after being successfully
    downloaded.


    > Here is an excerpt from the log of one of the machines that is failing to
    > install Windows Vista Service Pack 2:



    > 2009-10-09 06:24:26:189 1100 43240 Setup Client version: Core:
    > 7.2.6001.788
    > Aux: 7.2.6001.788


    You'll want to make sure you have a plan for upgrading the WSUS Server to
    SP2 as soon as possible.


    > 2009-10-09 06:24:32:070 1100 43240 PT + ServiceId =
    > {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL =
    > http://admsccmu2.na.admworld.com:80/ClientWebService/client.asmx


    You also should remove the port suffix from the URL configured in policy for
    the WSUS server. It's not necessary.


    > 2009-10-09 06:24:32:148 1100 43240 PT Initializing simple targeting
    > cookie,
    > clientId = 8acf3711-c735-4e6c-88c9-1f58d2f04d09, target group = CORP, DNS
    > name = 021_jbeals.na.admworld.com


    btw.. Underscores are not a valid character in the Domain Name Service -- a
    flaw in Microsoft DNS actually allows them to exist, but you should consider
    renaming them, or at least refraining from them using in future names.


    > 2009-10-09 06:24:32:148 1100 43240 PT Server URL =
    > http://admsccmu2.na.admworld.com:80/SimpleAuthWebService/SimpleAuth.asmx
    > 2009-10-09 06:24:35:549 1100 43240 Agent WARNING: Failed to evaluate
    > Installed rule, updateId = {87CFBD65-2BD8-434F-AE28-59E3A2018AF3}.1, hr =
    > 8004100E
    > 2009-10-09 06:24:35:549 1100 43240 Agent WARNING: Failed to evaluate
    > Installable rule, updateId = {87CFBD65-2BD8-434F-AE28-59E3A2018AF3}.1, hr
    > =
    > 8004100E
    > 2009-10-09 06:24:35:549 1100 43240 Agent WARNING: Failed to evaluate
    > Installed rule, updateId = {017CD15C-7188-4057-BFA1-1933409CA0AE}.1, hr =
    > 8004100E
    > 2009-10-09 06:24:35:549 1100 43240 Agent WARNING: Failed to evaluate
    > Installable rule, updateId = {017CD15C-7188-4057-BFA1-1933409CA0AE}.1, hr
    > =
    > 8004100E


    These warnings are suspicious. For one, the UpdateIDs are not in the
    Microsoft Catalog; for two, 0x8004xxxx error codes are highly unusual to be
    seen in a WU log. This error code is usually seen in response to a missing
    namespace in a WMI query. This could be an indication of a WMI issue on the
    local client.


    > 2009-10-09 06:24:42:896 1100 43240 Misc WARNING: WinHttp:
    > SendRequestToServerForFileInformation failed with 0x80190194
    > 2009-10-09 06:24:42:896 1100 43240 Misc WARNING: WinHttp:
    > ShouldFileBeDownloaded failed with 0x80190194
    > 2009-10-09 06:24:42:896 1100 43240 Agent WARNING: Fail to download eula
    > file
    > http://admsccmu2.na.admworld.com/Content/B5/F0950B606E4C05BFF99B0410E80CE4C077454BB5.txt
    > with error 0x80244019


    > 2009-10-09 06:24:42:912 1100 43240 Misc WARNING: WinHttp:
    > SendRequestToServerForFileInformation failed with 0x80190194
    > 2009-10-09 06:24:42:912 1100 43240 Misc WARNING: WinHttp:
    > ShouldFileBeDownloaded failed with 0x80190194
    > 2009-10-09 06:24:42:912 1100 43240 Agent WARNING: Fail to download eula
    > file
    > http://admsccmu2.na.admworld.com/Content/2C/85605E276A7D714B23CCE78FACE8F915F1B7242C.txt
    > with error 0x80244019


    So, the problem here is determining which updates these EULAs are supposed
    to be for; because the UpdateIDs identified in the earlier entries are not
    in the Microsoft Catalog.


    > 2009-10-09 09:07:03:602 2436 420c8 COMAPI -------------
    > 2009-10-09 09:07:03:602 2436 420c8 COMAPI -- START -- COMAPI: Search
    > [ClientId = CcmExec]
    > 2009-10-09 09:07:03:602 2436 420c8 COMAPI ---------


    This is a detection being initiated by SMS/SCCM (CcmExec) only 2.5 hours
    after the above detection,which appears to be a regularly schedule detection
    triggered by the WUAgent.

    Do you have two separate update methodologies in play here - SCCM *and*
    WSUS?


    > 2009-10-09 09:07:03:617 1100 434d8 Agent * Criteria = "UpdateID =
    > 'cad30b29-e5a2-42ed-bcdc-501208b47b91' AND DeploymentAction = *"


    *THIS* is the update package for Vista Service Pack 2 (KB948465)!
    Found by the SCCM scan, but not being found by the WSUS scan.


    > 2009-10-09 09:07:15:536 1100 434d8 Agent * Added update
    > {CAD30B29-E5A2-42ED-BCDC-501208B47B91}.102 to search result
    > 2009-10-09 09:07:15:551 1100 434d8 Agent * Found 1 updates and 59
    > categories in search; evaluated appl. rules of 130 out of 1281 deployed
    > entities


    > 2009-10-09 09:07:15:645 2436 43838 COMAPI WARNING:
    > ISusInternal::GetEulaText
    > failed, hr=80240033


    Which is again logged as failing, except this time with a code we know:
    0x80240033 -2145124301 WU_E_EULA_UNAVAILABLE EULA download failure


    --
    Lawrence Garvin, M.S., MCITP:EA, MCDBA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2009)

    My Blog: http://onsitechsolutions.spaces.live.com
    Microsoft WSUS Website: http://www.microsoft.com/wsus
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    Lawrence Garvin [MVP], Oct 9, 2009
    #2
    1. Advertising

  3. Dave Wright

    Dave Wright Guest

    Thanks for the quick response... See my responses below...

    "Lawrence Garvin [MVP]" wrote:

    > "Dave Wright" <> wrote in message
    > news:...
    >
    > >I am getting several updates that are failing on my System Center
    > > I've tried running WSUSUTIL /reset on the WSUS server

    >
    > So, probably the correct syntax for the command would be good. There is no
    > forward slash on the CLI parameters for wsusutil.exe.
    >
    > Just run WSUSUTIL RESET


    I rechecked, and we did run WSUSUTIL RESET without the slash. I typed it
    wrong in the message.

    > If a file download failed, it will be logged in the Application Event Log of
    > the WSUS Server;
    > it will also be logged in the WSUS SoftwareDistribution.log
    > found in the folder %ProgramFiles%\Update Services\Logfiles


    I'm requesting access to the logs from our IT Systems group. I probably
    won't get it until Monday.

    > HOWEVER -- the client would not be able to detect the availability of the
    > update unless the EULA had been previously downloaded, and the update
    > approved; so this is more likely a case of the file being *deleted*, rather
    > than never downloaded.


    This is most interesting, because the server is locked down pretty tight.
    I'm not sure how the file could have gotten deleted.

    > > The EULA HAS been accepted in the System Center Console on the updates in
    > > question.

    >
    > Assuming that WSUS is actually the configured SUP for SCCM; the EULA would
    > have had to physically exist in order to have been accepted; so here we also
    > have confirmation that the file was likely deleted after being successfully
    > downloaded.


    I re-verified this, and in the SCCM Console, the metadata does show accepted
    for all Eula's that are being deployed. Still makes me wonder how the data
    was deleted in the first place.

    > > 2009-10-09 06:24:26:189 1100 43240 Setup Client version: Core:
    > > 7.2.6001.788
    > > Aux: 7.2.6001.788

    >
    > You'll want to make sure you have a plan for upgrading the WSUS Server to
    > SP2 as soon as possible.


    It is on my plate. :)

    > > 2009-10-09 06:24:32:070 1100 43240 PT + ServiceId =
    > > {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL =
    > > http://admsccmu2.na.admworld.com:80/ClientWebService/client.asmx

    >
    > You also should remove the port suffix from the URL configured in policy for
    > the WSUS server. It's not necessary.


    I've had some issues with clients unable to connect to the server if the
    port is NOT specified. It may be a proxy issue there, but it seems that
    placing the port in the URL corrects the problem. Is there any problem with
    leaving this alone or do I run the risk of future problems?

    > btw.. Underscores are not a valid character in the Domain Name Service -- a
    > flaw in Microsoft DNS actually allows them to exist, but you should consider
    > renaming them, or at least refraining from them using in future names.


    This particular machine doesn't conform to our naming standards. Believe
    me, I want to get rid of them too. ;)

    > > 2009-10-09 06:24:32:148 1100 43240 PT Server URL =
    > > http://admsccmu2.na.admworld.com:80/SimpleAuthWebService/SimpleAuth.asmx
    > > 2009-10-09 06:24:35:549 1100 43240 Agent WARNING: Failed to evaluate
    > > Installed rule, updateId = {87CFBD65-2BD8-434F-AE28-59E3A2018AF3}.1, hr =
    > > 8004100E


    > These warnings are suspicious. For one, the UpdateIDs are not in the
    > Microsoft Catalog; for two, 0x8004xxxx error codes are highly unusual to be
    > seen in a WU log. This error code is usually seen in response to a missing
    > namespace in a WMI query. This could be an indication of a WMI issue on the
    > local client.


    I see these in almost all of my clients log files, even the ones that are
    not having any problems. I've generally been ignoring them because all seems
    to be working fine despite them. What do these mean?

    > So, the problem here is determining which updates these EULAs are supposed
    > to be for; because the UpdateIDs identified in the earlier entries are not
    > in the Microsoft Catalog.


    I'll do some additional investigating and see what I can find. I'm also
    going to have my systems guy re-run the WSUSUTIL RESET command.

    > This is a detection being initiated by SMS/SCCM (CcmExec) only 2.5 hours
    > after the above detection,which appears to be a regularly schedule detection
    > triggered by the WUAgent.
    >
    > Do you have two separate update methodologies in play here - SCCM *and*
    > WSUS?


    This is possible, and after checking on this machine likely. We are in the
    process of migrating to SCCM from WSUS. Roughly 2/3 of our clients have been
    migrated and 1/3 are still on WSUS only. This computer was in an OU in AD
    that was excluded from SCCM patching, but was still targetted for a test
    deployment in SCCM of Vista SP2. I moved the machine out of the old WSUS OU
    and into the an OU being patched by SCCM.

    One thing I am confused about though, and maybe you can clear this up for
    me. Under WSUS we used the WUAUCLT.EXE file with it's /DETECTNOW switch to
    force a machine to detect updates. Under SCCM we use the SCCM client action
    to initiate Software Updates Scan Cycle, but I've been told we can also use
    the old WSUS method. Is there a difference between the two methods or do
    they accomplish the same thing? Or was I given bad information and they are
    like apples and oranges?

    > > 2009-10-09 09:07:03:617 1100 434d8 Agent * Criteria = "UpdateID =
    > > 'cad30b29-e5a2-42ed-bcdc-501208b47b91' AND DeploymentAction = *"


    > *THIS* is the update package for Vista Service Pack 2 (KB948465)!
    > Found by the SCCM scan, but not being found by the WSUS scan.


    That is weird. Why would one scan pick it up and not the other?

    > > 2009-10-09 09:07:15:645 2436 43838 COMAPI WARNING:
    > > ISusInternal::GetEulaText
    > > failed, hr=80240033


    > Which is again logged as failing, except this time with a code we know:
    > 0x80240033 -2145124301 WU_E_EULA_UNAVAILABLE EULA download failure


    OK, so this does confirm that Vista SP2 is failing because of the EULA.

    Thanks for the insight so far. I've learned lots from just one post. :)
    Monday, after I get access to the server logs and I have my server guy re-run
    the WSUSUTIL RESET command, I will check the client again and see if anything
    has changed and post details here.

    --Dave Wright
    Dave Wright, Oct 10, 2009
    #3
  4. "Dave Wright" <> wrote in message
    news:...

    >> If a file download failed, it will be logged in the Application Event Log
    >> of
    >> the WSUS Server;
    >> it will also be logged in the WSUS SoftwareDistribution.log
    >> found in the folder %ProgramFiles%\Update Services\Logfiles

    >
    > I'm requesting access to the logs from our IT Systems group. I probably
    > won't get it until Monday.


    Can you give me some background on the interrelationships here?

    Are you the primary WSUS Administrator? Do you not have access to the WSUS
    Server directly?
    I'm really intrigued that you'd have to "request access" to these logs! :-/

    Also, if access to the logs requires a special request -- we may have
    significant issues performing diagnostics and testing trying to identify the
    cause of this issue. (And you allude to this by indicating how "locked down"
    this server is.)


    > I'm not sure how the file could have gotten deleted.


    It might not have been deleted. It could also be the victim of an ACL
    change, a filesystem move, or other *controlled* activities which result in
    a change being made that functionally hides the file from the Update
    Services service. It might have been moved into a tree that's causing an
    invalid ACL inheritance. If that server really is locked down as tight as it
    seems, then it should be trivial for that System Administrator to identify
    when that file first appeared on the server and when it "disappeared" (or
    where it actually is at this moment).


    >> > 2009-10-09 06:24:32:070 1100 43240 PT + ServiceId =
    >> > {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL =
    >> > http://admsccmu2.na.admworld.com:80/ClientWebService/client.asmx

    >>
    >> You also should remove the port suffix from the URL configured in policy
    >> for
    >> the WSUS server. It's not necessary.

    >
    > I've had some issues with clients unable to connect to the server if the
    > port is NOT specified. It may be a proxy issue there, but it seems that
    > placing the port in the URL corrects the problem.


    That would definitely be a proxy issue, I'd think. The proxy may not be
    properly assuming a default port of 80; or may be appending the wrong port
    number onto the URL as it passed it through. Basic point, though, the HTTP
    specification says all HTTP listeners should respond on port 80 if/when the
    port number is not specified, so if the proxy is messing with that -- it's
    either a misconfiguration of the proxy server, or the proxy server is not
    fully protocol compliant.

    > Is there any problem with leaving this alone or do I run the risk of
    > future problems?


    If it's not causing any problems now, and removing it does, then I'd say
    leave it alone. I can't say that I remember any direct issues caused by the
    suffix, but I do know there's a reason I started recommending removing the
    :80 suffix. I probably should review my Sent Items archive and see if I can
    refresh my memory on why I started doing that.


    >> btw.. Underscores are not a valid character in the Domain Name Service --
    >> a
    >> flaw in Microsoft DNS actually allows them to exist, but you should
    >> consider
    >> renaming them, or at least refraining from them using in future names.

    >
    > This particular machine doesn't conform to our naming standards. Believe
    > me, I want to get rid of them too. ;)


    <G>

    Well.. maybe you have a good reason here -- it has a dysfunctional WUAgent
    and cannot be maintained in a 'secure' state. ;-)


    >> > 2009-10-09 06:24:32:148 1100 43240 PT Server URL =
    >> > http://admsccmu2.na.admworld.com:80/SimpleAuthWebService/SimpleAuth.asmx
    >> > 2009-10-09 06:24:35:549 1100 43240 Agent WARNING: Failed to evaluate
    >> > Installed rule, updateId = {87CFBD65-2BD8-434F-AE28-59E3A2018AF3}.1, hr
    >> > =
    >> > 8004100E

    >
    >> These warnings are suspicious. For one, the UpdateIDs are not in the
    >> Microsoft Catalog; for two, 0x8004xxxx error codes are highly unusual to
    >> be
    >> seen in a WU log. This error code is usually seen in response to a
    >> missing
    >> namespace in a WMI query. This could be an indication of a WMI issue on
    >> the
    >> local client.

    >
    > I see these in almost all of my clients log files, even the ones that are
    > not having any problems. I've generally been ignoring them because all
    > seems
    > to be working fine despite them. What do these mean?


    There was an issue a few weeks (months? time runs all together these days)
    ago, where the WUAgent was "seeing" updates that weren't suppose to be seen.
    A 'fix' for that issue was supposed to be released, and once the issue was
    acknowledged and we determined the issue was benign, I went on to other
    issues. It may be that this is related to that 'bug', and it's not actually
    been fixed (or you might not have the fix). Let me do some research on that
    issue and see what came of it.

    >> So, the problem here is determining which updates these EULAs are
    >> supposed
    >> to be for; because the UpdateIDs identified in the earlier entries are
    >> not
    >> in the Microsoft Catalog.

    >
    > I'll do some additional investigating and see what I can find. I'm also
    > going to have my systems guy re-run the WSUSUTIL RESET command.


    Make sure the server does not have any pending downloads, if the 'reset'
    command creates new download requests, that they're actually executed.


    >> This is a detection being initiated by SMS/SCCM (CcmExec) only 2.5 hours
    >> after the above detection,which appears to be a regularly schedule
    >> detection
    >> triggered by the WUAgent.
    >>
    >> Do you have two separate update methodologies in play here - SCCM *and*
    >> WSUS?

    >
    > This is possible, and after checking on this machine likely.


    That *could* be causing some miscommunication (and misreported status)
    between the two systems.

    > We are in the process of migrating to SCCM from WSUS. Roughly 2/3 of our
    > clients have been
    > migrated and 1/3 are still on WSUS only. This computer was in an OU in AD
    > that was excluded from SCCM patching, but was still targetted for a test
    > deployment in SCCM of Vista SP2. I moved the machine out of the old WSUS
    > OU
    > and into the an OU being patched by SCCM.


    AHHH!!!... Something you need to be aware of. It's a natural behavior of
    Group Policy. Moving a machine out of the "WSUS" OU, and into an 'SCCM" OU
    will *not* deactivate the WSUS configuration, unless the policy settings
    have been explicitly disabled (or modified) by the "SCCM" OU. I would
    suggest verifying that all of the policy differentials between those two OUs
    are being handled as expected.



    > One thing I am confused about though, and maybe you can clear this up for
    > me. Under WSUS we used the WUAUCLT.EXE file with it's /DETECTNOW switch
    > to
    > force a machine to detect updates. Under SCCM we use the SCCM client
    > action
    > to initiate Software Updates Scan Cycle, but I've been told we can also
    > use
    > the old WSUS method. Is there a difference between the two methods or do
    > they accomplish the same thing? Or was I given bad information and they
    > are
    > like apples and oranges?


    It's really two different client-side scenarios, and is also dependent upon
    whether WSUS is being used as the SUP for SCCM. I'm still learning the
    SCCM/WSUS scenario, so I'm by no means an expert on this, and you might find
    a better (read: more accurate) answer in the SCCM forum(s).

    The WSUS environment uses the native Windows Update Agent, as is done with
    Automatic Updates, Windows Update, or Microsoft Update.

    SCCM has it's own custom agent. Now, what I'm not sure about is whether this
    agent proxies through the WUAgent, or actually queries directly to the CM
    server. Also, that's probably dependent on whether WSUS is being used as the
    SCCM SUP, or not.

    Using the old "WSUS method" (e.g. using the WUAgent) would require, I
    believe, that WSUS is configured as the SCCM SUP.


    >> > 2009-10-09 09:07:03:617 1100 434d8 Agent * Criteria = "UpdateID =
    >> > 'cad30b29-e5a2-42ed-bcdc-501208b47b91' AND DeploymentAction = *"

    >
    >> *THIS* is the update package for Vista Service Pack 2 (KB948465)!
    >> Found by the SCCM scan, but not being found by the WSUS scan.

    >
    > That is weird. Why would one scan pick it up and not the other?


    It may not actually be approved in the *WSUS* environment, or it may not be
    approved for the *group* that this client is now detecting against with the
    WSUS Server. If the client was configured in target group 'A' under the
    "WSUS" GPO, and moving it to the "SCCM" GPO has caused client-side targeting
    to be disabled, or the client to be placed in target group 'B', the update
    may not be visible to the WUAgent from WSUS.


    >> > 2009-10-09 09:07:15:645 2436 43838 COMAPI WARNING:
    >> > ISusInternal::GetEulaText failed, hr=80240033

    >
    >> Which is again logged as failing, except this time with a code we know:
    >> 0x80240033 -2145124301 WU_E_EULA_UNAVAILABLE EULA download failure

    >
    > OK, so this does confirm that Vista SP2 is failing because of the EULA.


    Yes, at least from the SCCM environment.



    --
    Lawrence Garvin, M.S., MCITP:EA, MCDBA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2009)

    My Blog: http://onsitechsolutions.spaces.live.com
    Microsoft WSUS Website: http://www.microsoft.com/wsus
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    Lawrence Garvin [MVP], Oct 10, 2009
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Maxalons

    Error: Download Failed 0x80244019

    Maxalons, Dec 21, 2004, in forum: Windows Update
    Replies:
    1
    Views:
    264
    Harish.G [MSFT]
    Dec 22, 2004
  2. JT

    Error: Download Failed 0x80244019

    JT, Jan 23, 2006, in forum: Windows Update
    Replies:
    1
    Views:
    199
    MowGreen [MVP]
    Jan 23, 2006
  3. rvvisse

    WSUS Download failed, error = 0x80244019

    rvvisse, Oct 13, 2009, in forum: Windows Update
    Replies:
    9
    Views:
    4,187
    rvvisse
    Oct 15, 2009
  4. Johnty

    Download failed error code 0x80244019

    Johnty, Jun 24, 2005, in forum: Update Services
    Replies:
    0
    Views:
    151
    Johnty
    Jun 24, 2005
  5. Marco

    Error 0x80244019 fail to download.

    Marco, Mar 21, 2006, in forum: Update Services
    Replies:
    0
    Views:
    186
    Marco
    Mar 21, 2006
Loading...

Share This Page