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 uring 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, 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."

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