WSUS 3.0 - The server is failing to download some updates

Error:
Event Type: Error
Event Source: Windows Server Update Services
Event Category: Core
Event ID: 10032
Date: 2007/05/28
Time: 11:58:40 AM
User: N/A
Computer: XXXXX
Description:
The server is failing to download some updates.

1) No other WSUS errors logged in event log
2) wsusutil checkhealth shows this as the only issue
3) As far as I can see from the update logs, only one warning:

Warning w3wp.12 SoapUtilities.CreateException ThrowException: actor =
https://server:8531/ClientWebService/client.asmx, ID=6d1019b8-
f68c-4780-a2e7-e2ff08ac62ff, ErrorCode=ServerChanged, Message=Server
rolled back since last call to GetCookie, Client=c96cc21b-
b626-495f-8710-9666ee409689

4) I abolutely hate seeing an error in the event log, esp as I do not
know *why* this is occurring and even more, where can I actually check
to see *which* updates are failing. I'd hate to rebuild this from
scratch.
5) The upstream server is MU, and all sync's are looking OK.
6) As far as I can see clients are connecting and getting updated.
7) This server was upgraded from WSUS2 SP1, and the database has been
moved to SQL 2005 as per procedure in installation notes. I do not see
any problems on the DB side though.

Any pointers appreciated.

Have you determined which updates are failing to download?

What can you tell me about the environment? Is the WSUS server configured to
use a proxy? If so, what proxy server do you use? Do you have the ability to
configure the proxy server, or does somebody else own that system? If
somebody else owns it.. have they changed anything on it?

If using a proxy configuration, did you address the issue described in the
very first paragraph of the Release Notes, after performing your upgrade?
Important configuration issue: You must overwrite the proxy server password
in the configuration wizard
If you are using a proxy server that requires user name/password
authentication, the WSUS server may fail to synchronize updates if you do
not overwrite the proxy server password when running the WSUS Server
Configuration Wizard. Because the configuration wizard is launched
automatically at the end of setup, this problem can cause synchronization
errors after you upgrade to WSUS 3.0 from an older version of WSUS.

You can avoid this problem by cancelling the configuration wizard after
upgrade, or by re-entering the correct proxy password when the configuration
wizard runs. To recover from this problem after it has occurred, go to
Update Source and Proxy Server on the Options page, re-enter the proxy
password, and then save the setting.

This is the *client* log, and has absolutely nothing to do with the above
error found in the Event Log.

1) The server is using an ISA 2006 box as proxy, and the rule is
unauthenticated. I have full control over that box.
2) WSUS is running on a mngmt server, and we also download Trend AV
updates on this box via ISA, no issues.
3) The server was never configured to use any proxy pwds
4) I've checked our OPSNotices and no changes were made on the ISA box
(will follow up and double check though, will also check the ISA logs
just to be sure)
5) The weird thing is that WSUS does not specify "which" updates
aren't being downloaded!
6) FYI: Just looked at the last couple of hours and summary of events:

a. 18:07 - The server is failing to download some updates
b. 23:07 - Catalog last syn'ed 1 or more days ago
c. 12:07 - The server is failing to download some updates
d. 01:02 - (WSUS MMC) - Sync OK, 4 new updates, 5 expired
e. 06:07 - The server is failing to download some updates

7) *No* other warnings or alerts in the event logs either side of all
these events...
8) I've done other in-place upgrades of 3.0 at other clients, but they
all seem to be fine.

Actually, it does, it just doesn't give it to you on a silver platter.

Scan the list of updates in the Admin Console and reconcile the updates that
are approved against the updates that are downloaded, or are not downloaded.

Thanks.
OK under "All updates" I saw a number of updates that show "failed".
Most of them had the "This file has not been downloaded...". I
cancelled the download, and then re-approved all of them.
The error message is now gone and I get the "WSUS is healthy message",
*but*, and this is the q behind my q: after about 12 hours I still
have the same downloads in the list, all still show failed, and all
the ones that were not downloaded still have the same status...

I guess that for the failed ones we can look at the specific clients
involved, might be specific issues on those units (normally there is
about 1 out of 250 odd that had an issue). As for the ones that remain
"undownloaded", simply don't know. I don't want to decline those?

Again, tx for your help.

An indication that the downloads are still failing.

But, at least you now know which ones. Next Q: Are *all* of the downloads
failing, or just some of them?

These are not failures of the client downloading from the WSUS server...
they are a failure of the WSUS server downloading from it's upstream server
(microsoft.com in a single server deployment).

The most common cause for this failure is interference from a proxy server
or firewall.

There seems to be about 10 or so failing, all the others are
fine...which is really puzzling. (And of course today the error is
back in the log...)

I'm about to just give up and do a clean install really; taking far
more time than it is worth to be honest. I love troubleshooting but
I've got multiple other projects running so I'm going to get rid of
this thorn in the flesh in the shortest possible way I guess.

Thanks for the help anyway!

Hi I am having a similar problem, but ALL of my updates are failing.
I did not upgrade from version 2 this is a clean install of version 3.
My server is not using a proxy.
It is behind a Sonicwall firewall, but version 2 was working behind
the same firewall.

WSUS is running on a server running Windwos Server 2003 Web Edition.
The server is also running Ipswitch's Whats Up Gold.
Thanks

Hi I am having a similar problem, but ALL of my updates are failing.
I did not upgrade from version 2 this is a clean install of version 3.
My server is not using a proxy.
It is behind a Sonicwall firewall, but version 2 was working behind
the same firewall. On that firewall ports 80 and 443 are open for all
outbound traffic.

WSUS is running on a server running Windwos Server 2003 Web Edition.
The server is also running Ipswitch's Whats Up Gold.
Have you found a solution?

Well... given the history of SonicWall being non-compliant with protocols,
I'd suggest starting with SonicWall technical support.

Unless version 2 was working because you put BITS in "foreground" mode,
which would have hidden any interference from your SonicWall device, and the
necessary HTTP v1.1 protocols needed to support BITS in "background" mode.

[Khalid Saeed]

We have 4 different servers at different cities. We installed WSUS and it was working fine.

But when we approved Windows XP Service Pack 3, it stopped downlading this update on all the servers.

I dont think that there is a problem with firewall or proxy, because we are not using any proxy or firewall and earlier it was working perfactly fine.

[yeiyei1986]

Hey. I have the same problem here.

Try this to get the problem solved.

1. if you have WSUS in a Domain controler computer you may have to grant to the folder of wsus (the one selecte in wsus intalation) to user NETWORK SERVICE whith full access.
2. in the data base selected for wsus use grant access of db_owner to NETWORK SERVICE user.

this works for me.

Not unless somebody has changed the parent permissions, or employed a
Security Template after WSUS was installed.

WSUS properly creates all necessary NTFS permissions on WSUS-created
resources.

It *may* be necessary to grant the NETWORK SERVICE account READ permissions
on a non-SYSVOL drive where the \WSUS folder is created, if that has not
been previously done. If you were experiencing issues downloading updates to
a non-SYSVOL drive -- THIS is the change you probably should have made.

The NETWORK SERVICE account does not need any permissions on the \WSUS
folder, but should have
- Full Control permissions on the ~\WSUS\UpdateServicesDBFiles folder and
inherited down
- Full Control permissions on the ~\WSUS\WSUSContent folder and inherited
down
- Read/Write permissions on the ~\WSUS\UpdateServicesPackages folder and
inherited down
- Read & Execute / List Folder Contents / Read permissions on the
%ProgramFiles%\Update Services folder and inherited down.

The permissions have no significance whether WSUS is installed on a DC, a
member server, or a standalone server. The NETWORK SERVICE account is not a
domain member, and exists on all machines.

If you encountered security issues that were "fixed" by granting the
permissions you have documented, you have applied incorrect permissions
changes, and in any event there is absolutely no reason to change the
permissions inside the database.

The correct permissions are documented in the WSUS Operations Guide. You may
want to reconcile your entire installation with those documented permissions
to ensure you have not unnecessarily created any security thruways.

[MBrunzlik]

It seems that the last entry in your list of folder permissions is incorrect!

We have just moved our WSUS server from one server to another as it ran out of space and in the process we installed the latest WSUS 3.0 SP2 with SQL 2005 on the new server and experienced the same issues described in the above posts – down to the Application Event log reporting directory creation failure by WSUS.

Prior to doing the new WSUS install we used Robocopy to copy the \WSUS\WSUSContent folder across to the new server using the "mirror" option expecting that all permissions would be copied too since both servers are in the same AD domain. We did a WSUS database dump and imported it from the old to the new server prior to the install as well.

We applied your suggested folder permissions and then we get a connection error in the WSUS console! To confirm our suspicion of which folder was the cause we added Everyone with Full Control to the /Program Files/Update Services folder and propagated them downwards and the console can now connect again. So there must be a problem in applying the permissions you suggested to this folder.

Since we don't know what the original permissions were (especially to all the sub folders), we can't revert. I can't find anything in the WSUS help or in TechNet regarding the permissions that the WSUS folders (and sub-folders) must have and we have already trashed the WSUS tree on the old server so can't use it as a reference.

I guess I'll have to re-install and be more careful what permissions are applied next time around.

It would be useful to have the correct permissions listed here for future reference. I'll update here if nobody else does once we have re-installed.

"MBrunzlik" <MBrunzlik.403hvd@DoNotSpam.com> wrote in message
news:MBrunzlik.403hvd@DoNotSpam.com...

It would have been helpful to have quoted the relevant portion of the
message/poster to which you are replying. I believe this is the item you're
commenting about, since the threadmap shows your reply directed at my post:

A reasonable goal; however, strictly speaking the correct methodology would
be to robocopy the SUBfolders of \WSUS\WSUSContent to \WSUS\WSUSContent on
the new server, *after* installing WSUS on the new server, so as to preserve
the permissions and inheritance configured on the target ~\WSUSContent
folder.

The fundamental flaw with using Robocopy is that it does not copy across
*LOCAL* accounts/groups where the SIDs are different. Since both the "WSUS
Administrators" and "WSUS Reporters" groups are local groups with unique
SIDs, the former being the critical point here -- the creation of resources
(including the group itself) using the "WSUS Administrators" group is
necessary. Copying the ~\WSUS folder may have created an ACL on the target
folder with a SID for a non-existent group -- it's also possible that
Robocopy dropped the ACL entry, given that there was no matching SID in the
SAM.

Then, installing WSUS after the folder was created, so the installer has
"found" the existing folder, may or may not have resulted in the ACLs for
that folder being properly updated with the permissions for the *new* "WSUS
Administrators" group.

In short, the correct migration procedure is:
1. Install WSUS.
2. Verify the installation has produced a fully functional server.
3. Migrate database and content to an *installed* and *working* server.

I did not provide the complete list of required permissions, so I'm not sure
how my post has any relevance to copying the \WSUSContent folder or why you
are referring to "suggested folder permissions". Furthemore, the
\WSUSContent folder has nothing at all to do with the ability of the console
to connect to the WSUS server so your problem has absolutely nothing to do
with this thread or my post.

If you *installed* WSUS on the new server, you can trust that those
permissions are absolutely correct.

Furthermore, granting the whole world access to a resource doesn't prove
squat except now you've allowed the whole world to connect to everything --
of Course the console would now connect again! Furthemore, my folder
permissions were not comprehensive permissions -- I was merely commenting on
the permissions required for the NT AUTHORITY\Network Service account to the
*content* folder -- not anything at all related to console connections.

Unless you ROBOCOPYed the %ProgramFiles%\Update Services folder tree - why
would you distrust the INSTALLATION to properly set the permissions on the
%ProgramFiles% folder???

It also helps to understand how the console connects to the WSUS sever. The
Console session connects to the APIRemoting30 webservice, which is mapped to
the %ProgramFiles%\Update Services\webservices\xxx folder. The APIRemoting30
webservice is configured to require Windows Authentication -- that is to
say, the WSUS Server and the account used to execute/logon the console
session, must have a domain trust (Either it's a local account on the WSUS
Server, or a domain account in the domain in which the WSUS Server is a
member.)

So, if you were getting a connection error on the console, which was then
"fixed" by granting Everyone Full Control (again, never a useful test of
security issues), then the most likely cause is that you were not permitting
Authenticated Users connection to a resource that requires Authenticated
connections.

If you correctly *installed* the WSUS server on this machine, ACLs are not
the cause of this problem.

WSUS NTFS permissions are documented in Appendix D of the WSUS Operations
Guide [http://technet.microsoft.com/en-us/l...0(WS.10).aspx].

All of the permissions on webservices folders are inherited from the
WebServices folder. They should be:

Full Control
- Administrators
- SYSTEM

Read & Execute / List Folder Contents / Read
- Network Service
- Authenticated Users
- Users

and IIS needs to have Anonymous Access *disabled* for the APIRemoting30
virtual directory. The IIS permissions are documented in Appendix C
[http://technet.microsoft.com/en-us/l...3(WS.10).aspx]