WSUS 3.0 - The server is failing to download some updates
eugenevr
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.
Lawrence Garvin (MVP)
news:1180347779.4...@h2g2000hsg.googlegroups.com...
> 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
Okay....
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?
>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.
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.
> 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
This is the *client* log, and has absolutely nothing to do with the above
error found in the Event Log.
--
Lawrence Garvin, M.S., MCTS, MCP
Independent WSUS Evangelist
MVP-Software Distribution (2005-2007)
https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E
Everything you need for WSUS is at
http://technet2.microsoft.com/windowsserver/en/technologies/featured/wsus/default.mspx
And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
....
eugenevr
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.
*** Your help is appreciated!!
On 29 May, 00:49, "Lawrence Garvin \(MVP\)"
<onsit...@community.nospam> wrote:
> "eugenevr" <e...@yahoo.com> wrote in message
> MVP-Software Distribution (2005-2007)https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D09...
>
> Everything you need for WSUS is athttp://technet2.microsoft.com/windowsserver/en/technologies/featured/...
Lawrence Garvin (MVP)
> 5) The weird thing is that WSUS does not specify "which" updates
> aren't being downloaded!
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.
--
Lawrence Garvin, M.S., MCTS, MCP
Independent WSUS Evangelist
MVP-Software Distribution (2005-2007)
https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E
Everything you need for WSUS is at
http://technet2.microsoft.com/windowsserver/en/technologies/featured/wsus/default.mspx
eugenevr
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.
E
On 29 May, 08:43, "Lawrence Garvin \(MVP\)"
<onsit...@community.nospam> wrote:
> "eugenevr" <e...@yahoo.com> wrote in message
>
> news:1180418860....@q75g2000hsh.googlegroups.com...
>
> > 5) The weird thing is that WSUS does not specify "which" updates
> > aren't being downloaded!
>
> 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.
>
> --
> Lawrence Garvin, M.S., MCTS, MCP
> Independent WSUS Evangelist
> MVP-Software Distribution (2005-2007)https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D09...
>
> Everything you need for WSUS is athttp://technet2.microsoft.com/windowsserver/en/technologies/featured/...
Lawrence Garvin (MVP)
> 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...
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?
> 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?
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.
--
Lawrence Garvin, M.S., MCTS, MCP
Independent WSUS Evangelist
MVP-Software Distribution (2005-2007)
https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E
Everything you need for WSUS is at
http://technet2.microsoft.com/windowsserver/en/technologies/featured/wsus/default.mspx
eugenevr
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!
Eugene
On 30 May, 15:16, "Lawrence Garvin \(MVP\)"
<onsit...@community.nospam> wrote:
> "eugenevr" <e...@yahoo.com> wrote in message
>
> news:1180502506.0...@o5g2000hsb.googlegroups.com...
>
> > 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...
>
> 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?
>
> > 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?
>
> 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.
>
> --
> Lawrence Garvin, M.S., MCTS, MCP
> Independent WSUS Evangelist
> MVP-Software Distribution (2005-2007)https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D09...
>
> Everything you need for WSUS is athttp://technet2.microsoft.com/windowsserver/en/technologies/featured/...
emerso...@gmail.com
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.
Thanks
emerso...@gmail.com
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.
emerso...@gmail.com
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?
Thanks
Lawrence Garvin (MVP)
news:1180631346....@q19g2000prn.googlegroups.com...
>> > The most common cause for this failure is interference from a proxy
>> > server
>> > or firewall.
> 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.
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.
--
Lawrence Garvin, M.S., MCTS, MCP
Independent WSUS Evangelist
MVP-Software Distribution (2005-2007)
https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E
Everything you need for WSUS is at
http://technet2.microsoft.com/windowsserver/en/technologies/featured/wsus/default.mspx
And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
....
>> > --
>> > Lawrence Garvin, M.S., MCTS, MCP
>> > Independent WSUS Evangelist
>> > MVP-Software Distribution
>> > (2005-2007)https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D09...
>>
>> > Everything you need for WSUS is
>> > athttp://technet2.microsoft.com/windowsserver/en/technologies/featured/...
>>
>> > And, almost everything else is athttp://wsusinfo.onsitechsolutions.com
>> > ....
>
> Thanks
>
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.
Yeison G�mez
Colombia.
--
yeiyei1986
------------------------------------------------------------------------
yeiyei1986's Profile: http://forums.techarena.in/members/140209.htm
View this thread: http://forums.techarena.in/server-update-service/755273.htm
Lawrence Garvin [MVP]
news:yeiyei19...@DoNotSpam.com...
>
> 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.
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.
--
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
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's Profile: http://forums.techarena.in/members/144486.htm
Lawrence Garvin [MVP]
"MBrunzlik" <MBrunzli...@DoNotSpam.com> wrote in message
news:MBrunzli...@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:
>> The NETWORK SERVICE account does not need any permissions on the \WSUS
>> folder, but should have
>> - Read & Execute / List Folder Contents / Read permissions on the
>> %ProgramFiles%\Update Services folder and inherited down.
> 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.
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.
> We applied your suggested folder permissions and then we get a
> connection error in the WSUS console!
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.
> 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.
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.
> So there must be a problem in applying
> the permissions you suggested to this folder.
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.
> 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.
WSUS NTFS permissions are documented in Appendix D of the WSUS Operations
Guide [http://technet.microsoft.com/en-us/library/dd939790(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/library/dd939903(WS.10).aspx]