Software License Terms failing to download

I've got a challenge in front of me that has been irriatting me for almost a
week now. It started when Windows XP Service Pack 3 was synced to my WSUS
3.0 sp1 server. Now it has spread to four other updates. I can't approve
any of these updates because "Microsoft Software License Terms failed to
download. Cleick Retry Download to start the download again." For the XP
SP3 update I have done this several times now to no avial. So used
dogpile.com to find ather ideas as to what might be the cause, and subsequent
fix. None have worked.

I don't download the updates themselves, so I don't have a WSUSCONTENT
folder to worry about permissions. My computers install from Microsoft
Update. I've used "wsusutil reset" to no avial. All trying to fix the XP
SP3 problem. Then today I notice that four other updates are in the same
condition (two office related updates, and two Malicious Software Removal
Tool updates).

Now I'm almost to the point for calling PSS, but really don't want to do
that until absolutely necessary. So if any one else has come across this
problem and solved it please point me in the right direction.

Before we dive off into the EULA question.... exactly how many PCs are you
updating from this WSUS Server?

Consider the impact of each of these PCs performing individual downloads of
a 325MB service pack.

Yeah.. 'wsusutil reset' is pretty much worthless if you've configured the
server not to maintain a content store.

I've never actually analyzed how EULA content is obtained/managed. In some
cases it was stored as a TXT file in the content store, which could be
problematic if you don't have a content store. I'm also not sure if they're
obtained during =synchronization= or if they're obtained dynamically when
the "Approve" option is first selected, or whether there's any variance in
where they're stored (database, CABs, TXT files).

Not being able to access the EULA file is a common issue. When it is
'fixed', it's fixed by running 'wsusutil reset' which causes the refresh of
the content store -- but, as noted, that's not likely to be successful on a
machine with no content store.

Have you confirmed (just for grins), that the WSUS Console confirms there
are =0= files to be downloaded?

I'll see if I can get some better detail on how EULAs are handled.

53 devices ( 40 XP PCs, 5 Vista PCs and 8 Servers)

Yes I have considered that, and understand the impact. This configuration
was carefuly considered due to how many disparate locations report to this
server and resources available at those locations. An update like this
would not get approved during business hours, hopefully causing the
downloads to occur during those same non-business hours. Plus the update
would not be approved server wide, but by groups which corresponds to the
location. A little bit more administrative overhead, but a price that we
are willing to pay (right now).

Since I can't approve the update, I guess that the EULA would never get
downloaded, so that just defeats the purpose.

Yes, that's the first thing that I checked, even after "retrying the
download".

Thank you for the extra details. Your scenario makes much more sense with
that information known.

In fact, when the update gets =approved= has absolutely nothing to do with
when the content will actually be downloaded, except that I can guarantee
you no PC will download the SP before the update is approved for
installation.

Once the update is approved, it becomes "visible" to the PCs. Sometime
during the next 22 hours, each PC will execute it's next regularly scheduled
detection event. Some PCs could start as soon as microseconds after the
approval is posted; some PCs might not actually execute another detection
until 20+ hours after the approval is posted.

What is certain, though, is that unless you've implemented BITS policies on
each of your PCs/sites, each of those PCs will initiate a download of the
375MB service pack immediately upon executing and successfully completing
that detection event. Net Effect: You can expect to have PCs downloading SP
content around the clock for the next 24 hours (at least). How long it will
continue actually depends on how much composite Internet bandwidth you have
for those 40 XP PCs, and how much BITS actually gets to use.

This is good... the 22+hours after approval time frame still applies,
however; just staggered by location in this scenario..

The EULA must be available in order to successfully approve the update. All
I'm saying is that I don't know whether it's downloaded during
synchronization, or dynamically when you click on the Approve button. But
without the EULA, the update cannot be approved.

I sent off an email late last night. I'm still waiting on a reply. It could
take a couple of days by the time it filters through the "channels", and
across the weekend.

While we're waiting on an "official" reply from the WSUS team, in another
thread, posted today, success was reported by simply right-clicking on the
update listing in the WSUS Admin Console and selecting the option to
(re)download the update.

Tried that again several times for each update again this morning. Still no
joy, no change.

I got the "official" response back from the WSUS team today. Here are the
salient facts:

1. Immediately following synchronization, any required EULA files are
downloaded.

2. EULA files are stored in the ~\WSUSContent folder.

3. EULA files are shared among product with the same EULA, so the absence of
one EULA file can affect several updates.

4. The only known reasons for the "EULA not found" message are the four I've
already noted:
[a] The file has never been downloaded.
[b] The file was previously downloaded, but deleted subsequent to the
download.
[c] The permissions on ~\WSUSContent or the appropriate subfolder of
that folder tree are incorrect.
[d] The content store has been deleted, moved, renamed -- in which case
the WSUS Server wouldn't be seeing anything.

5. 'wsusutil reset will fix a missing EULA file problem on all WSUS 2.0 SP1
or later versions. WSUS 2.0 RTM did not download the missing EULA file in
response to a reset command.

6. There are no issues known to the WSUS team (at this time), where the
problem wasn't traced back to a missing file.

Given everything we've discussed - knowing the permissions are correct [c],
the core configs are correct [d], and that 'wsusutil reset' would resolve
any issues with [b], that leaves us with [a].

Possibly something in the server or network environment is "...preventing
the contact sync agent from downloading the EULA file."

[bigwheat]

I am experiencing the exact same problem, and have a pretty much identical setup. My problems didn't start until XP SP3 either. I've tried a number of different solutions (most all of them suggested by Lawrence on other posts), but have still not solved the issue.

What could possibly be causing the sync agent to not download the EULA file, yet have no problems with any other download? I'm not even sure where to begin looking for this...

Actually no files are downloaded - we are just like Art, we do not download to the content store, so it is empty. I'm assuming that this is where I would look to find the EULA file? If so, then it is indeed missing.

I tried 'wsusutil reset' - I saw your suggestion for that in another post, but no luck.

The following error is in the Application Event Log after retrying a download:
Content file download failed. Reason: Error calling [kernel32.dll]:CreateDirectory(C:\Program Files\Update Services\WsusContent\2C) Source File: Destination File: .

Which sounds like a permissions issue maybe? Network Service account does have access to the WsusContent folder - I know you had mentioned that in another post as well...

It's strange that we never had a problem until Windows XP SP3 was released.

First question is are you positive (100%) that the only files that
won't/aren't downloaded are EULAs?

EULAs are generally TXT files -- any possibility they're being blocked by
the firewall?

Second possibility is that the metadata says it's been downloaded, but it's
physically missing, which would cause the UI to gripe about the missing
EULA.

Generally this is fixable by issuing a 'wsusutil reset' command.

Beyond that, the next best step is to try to determine if the file is
physically missing, or if the UI just can't find it.

Then the next place I'd look is the Application Event log to see if WSUS is
logging a reason for any failed downloads. Also verify that you can download
files to this machine through your firewall.

We have seen this one other time where no content store was maintained and
EULA files did not come down, but the WSUS team has assured me there should
be no reason why EULAs fail to download in this configuration. EULAs are
downloaded during synchronization -- so also verify you haven't logged any
synchronization errors or synchronization failures.

Download the following tool:

http://download.microsoft.com/downlo...bug%20Tool.EXE

And run the following in a command Prompt:

wsusdebugtool /tool:setforegrounddownload

Thanks!
Abhi