Fail to download eula file with error 0x80244019
Dave Wright
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
Lawrence Garvin [MVP]
news:0D94A5CD-AE39-4909...@microsoft.com...
>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
Dave Wright
"Lawrence Garvin [MVP]" wrote:
> "Dave Wright" <DaveW...@discussions.microsoft.com> wrote in message
> news:0D94A5CD-AE39-4909...@microsoft.com...
>
> >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
Lawrence Garvin [MVP]
>> 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.