UAWGMCHR
asked on
Client computers no longer able to download updates from WSUS 3.0 SP1 Server
The vast majority of clients on our network have been unable to to pull down updates from our WSUS server (running WSUS 3.0 Service Pack 1) for a couple of weeks now.
The server itself seems to be runing fine. It is able to synchronize with the MU site and it is able to pull down newly released updates. I am also able to approve these updates and do other things within the WSUS console with no problem or errors.
As far as the clients go, the vast majority of them have been unable to install the handful of updates approved since the middlel of April. They appear to be trying nightly to pull in the updates but they fail each time - reporting error 0x80244019.
When I manually initiate my clients to look for updates using the "wuauclt /detectnow" command, I do see the standard update icon appear in the system toobar for a few seconds before it disappears. It seems like the clients are doing everything right until they need to download the updates and everything then blows up.
I have also attached a portion of the windowsupdate log from one of my clients.
I have already tried the steps mentioned in this microsoft knowledge base article:
http://support.microsoft.com/kb/959894
although this speaks to problems pulling updates from the Microsoft update site, it is the only relative hit I got when searching on error 0x80244019.
Also, I am able to go out directly to the MU website and successfully pull in updates on my clients. That is why I think the root problem is with the WSUS server itself.
One last possible smoking gun - we also installed Symantec Endpoint on this same server a couple of weeks ago. We haven't yet removed that software but our problems did crop up around the same time that was installed. We don't want to uninstall it just yet until we find out if our WSUS problems might be caused by something else.
This issue is worth the max since we have 100's of clients not getting the updates they need.
Appreciate you help
but then it disappears.
Windows-Update-Log.txt.txt
The server itself seems to be runing fine. It is able to synchronize with the MU site and it is able to pull down newly released updates. I am also able to approve these updates and do other things within the WSUS console with no problem or errors.
As far as the clients go, the vast majority of them have been unable to install the handful of updates approved since the middlel of April. They appear to be trying nightly to pull in the updates but they fail each time - reporting error 0x80244019.
When I manually initiate my clients to look for updates using the "wuauclt /detectnow" command, I do see the standard update icon appear in the system toobar for a few seconds before it disappears. It seems like the clients are doing everything right until they need to download the updates and everything then blows up.
I have also attached a portion of the windowsupdate log from one of my clients.
I have already tried the steps mentioned in this microsoft knowledge base article:
http://support.microsoft.com/kb/959894
although this speaks to problems pulling updates from the Microsoft update site, it is the only relative hit I got when searching on error 0x80244019.
Also, I am able to go out directly to the MU website and successfully pull in updates on my clients. That is why I think the root problem is with the WSUS server itself.
One last possible smoking gun - we also installed Symantec Endpoint on this same server a couple of weeks ago. We haven't yet removed that software but our problems did crop up around the same time that was installed. We don't want to uninstall it just yet until we find out if our WSUS problems might be caused by something else.
This issue is worth the max since we have 100's of clients not getting the updates they need.
Appreciate you help
but then it disappears.
Windows-Update-Log.txt.txt
Also read here
http://www.microsoft.com/communities/newsgroups/en-us/default.aspx?dg=microsoft.public.windows.server.update_services&tid=51f6ef04-13af-444e-92d2-190b07dbd436&cat=en_US_d02fc761-3f6b-402c-82f6-ba1a8875c1a7&lang=en&cr=&sloc=en-us&m=1&p=1
This is an HTTP 404 error. The requested URL does not exist.
Either the file is no longer physically present in
~\WSUSContent\C5\9BDF...17
or the IIS Virtual Directory is not properly linked to the ~\WSUSContent
folder,
or URLScan (or some other filtering tool) is blocking access to the download
of EXE files.
http://www.microsoft.com/communities/newsgroups/en-us/default.aspx?dg=microsoft.public.windows.server.update_services&tid=51f6ef04-13af-444e-92d2-190b07dbd436&cat=en_US_d02fc761-3f6b-402c-82f6-ba1a8875c1a7&lang=en&cr=&sloc=en-us&m=1&p=1
This is an HTTP 404 error. The requested URL does not exist.
Either the file is no longer physically present in
~\WSUSContent\C5\9BDF...17
or the IIS Virtual Directory is not properly linked to the ~\WSUSContent
folder,
or URLScan (or some other filtering tool) is blocking access to the download
of EXE files.
ASKER
ram kerala,
I checked those settings and this is what I found.
- WSUS is version 3.1.6001.65 which I believe is 3.0 SP1
- The group policy that pushes out the WSUS settings to our clients does reference "http://servername"
- IIS settings are a little more complicated.
Under IIS, there is a section "Application Pools" called "wsuspool"
And under "wsuspool" there are directories called
ClientWebService
SimpleAuthWebServices
Others too but no "SelfUpdate"
There is also a section called "websites" and under that "Default Web Site" that contains all three of the directories you mentioned. It is under this section that I made the changes you mentioned. I have attached a bmp that show this breakout.
Finally, when I changed the directory security settings and not use Anonymous and then tried to restart the wsus-related services, I got errors. Had to leave anonymous checked although I did also check Integrated windows auth.
Finally, problem still exists despite changes.
dstewartjr,
I looked at those links. The first one taked about a urlscan tool. I looked for a urlscan.ini file on our wsus server and did not find one. WSUS server also does not have a c:\winnt\system32\inetserv
the second one seemed promising but i was able to browse to a .txt file in one of the sub-folders under wsuscontent and save it to a client that cannot download updates. Was able to do the same for .cab and .exe files.
we even went so far as to uninstall the Symantec Endpoint Security server application from our wsus server today but clients still won't pull in updates. The symantec app also tweaked the IIS settings (as it uses IIS too) and even though it has been uninstalled, I'm wondering if it damaged the wsus installaion beyond repair.
Any new thoughts? Also, some of those links mentioned errors that occur if the IIS virtual directory is no longer pointing to the wsuscontent folder. How do I verify that?
IIS-settings.bmp
I checked those settings and this is what I found.
- WSUS is version 3.1.6001.65 which I believe is 3.0 SP1
- The group policy that pushes out the WSUS settings to our clients does reference "http://servername"
- IIS settings are a little more complicated.
Under IIS, there is a section "Application Pools" called "wsuspool"
And under "wsuspool" there are directories called
ClientWebService
SimpleAuthWebServices
Others too but no "SelfUpdate"
There is also a section called "websites" and under that "Default Web Site" that contains all three of the directories you mentioned. It is under this section that I made the changes you mentioned. I have attached a bmp that show this breakout.
Finally, when I changed the directory security settings and not use Anonymous and then tried to restart the wsus-related services, I got errors. Had to leave anonymous checked although I did also check Integrated windows auth.
Finally, problem still exists despite changes.
dstewartjr,
I looked at those links. The first one taked about a urlscan tool. I looked for a urlscan.ini file on our wsus server and did not find one. WSUS server also does not have a c:\winnt\system32\inetserv
the second one seemed promising but i was able to browse to a .txt file in one of the sub-folders under wsuscontent and save it to a client that cannot download updates. Was able to do the same for .cab and .exe files.
we even went so far as to uninstall the Symantec Endpoint Security server application from our wsus server today but clients still won't pull in updates. The symantec app also tweaked the IIS settings (as it uses IIS too) and even though it has been uninstalled, I'm wondering if it damaged the wsus installaion beyond repair.
Any new thoughts? Also, some of those links mentioned errors that occur if the IIS virtual directory is no longer pointing to the wsuscontent folder. How do I verify that?
IIS-settings.bmp
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
dstewartjr,
Thanks for providing that last link. Turns out there was a missing virtual directory in IIS that was causing the error and that link helped me to realize that something was missing.
We were missing the "CONTENT" virtual directory and once I readded it, the majority of my clients were able to pull down the updates. Pretty confident that the symantec app we loaded on that server a few weeks ago must have jacked up the IIS settings.
Thanks for providing that last link. Turns out there was a missing virtual directory in IIS that was causing the error and that link helped me to realize that something was missing.
We were missing the "CONTENT" virtual directory and once I readded it, the majority of my clients were able to pull down the updates. Pretty confident that the symantec app we loaded on that server a few weeks ago must have jacked up the IIS settings.
Also is there any configuration changes done in WSUS server ( especially the policy part )
Also in an other scenario for the same error code the issue was solved with the following steps
1. upgrade my wsus to version 3 sp1.
2. In your security policy check that your server is configured to http://yourserver if so then go to your IIS and make sure the virtual directories under your defult webserver(not the wsus administration port 8530) have these directories configured correctly:
ClientWebService
Selfupdate
SimpleAuthWebServices
make sure in each of these directories the network services group got 'read + list' permissions.
under directory properties asp.net tab select version 2 or above.
under directory properties Directory Security unselect anonymous and select integrated windows authentication.