Fail to download eula file with error 0x80244019

Fail to download eula file with error 0x80244019

Post by RGF2ZSBXcm » Sun, 11 Oct 2009 01:05:01


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-Act
 
 
 

Fail to download eula file with error 0x80244019

Post by Lawrence G » Sun, 11 Oct 2009 07:25:02

Dave Wright" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...


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



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.



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.





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



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



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.



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.




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.



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 the update package for Vista Service Pack 2 (KB948465)!
Found by the SCCM scan, but not being found by the WSUS scan.




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


 
 
 

Fail to download eula file with error 0x80244019

Post by RGF2ZSBXcm » Mon, 12 Oct 2009 01:04:01

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

"Lawrence Garvin [MVP]" wrote:


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


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


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


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.


It is on my plate. :)


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?


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



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?


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 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?



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



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

 
 
 

Fail to download eula file with error 0x80244019

Post by Lawrence G » Mon, 12 Oct 2009 03:25:31

Dave Wright" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...


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.)



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).



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.


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.



<G>

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



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.


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



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


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.




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