Darylrese Posted November 29, 2012 Posted November 29, 2012 (edited) Hi, Our WSUS server has been running for a few weeks now but none of our workstations seem to be getting updates. The WSUS console states none of the computers have reported yet, all updates have been approved to the correct groups and are ready to go. We have a group policy in place for workstations to pull down updates from WSUS at 16:00 each day. As far as i can see the group policy is working, however we get the following error in event viewer on workstations just after 16:00hrs: The company that put it in have been pretty useless so far telling us its just taking a long time to replicate, however i find it virtually impossible that it should take 3 weeks to do so! Any ideas? None of the clients / servers have been getting updates since the summer Edited November 29, 2012 by Darylrese
techsup1983 Posted November 29, 2012 Posted November 29, 2012 Do you have the WSUS GPO's attached to the OU with computer accounts in?
Darylrese Posted November 29, 2012 Author Posted November 29, 2012 oh and here's the group policy in place on all workstations. Its linked at the top level under establishments [ATTACH=CONFIG]16111[/ATTACH]
Geoff Posted November 29, 2012 Posted November 29, 2012 Did you disable the proxy settings for WinHTTP on your clients after you implemented WSUS? Otherwise they will attempt to contact your WSUS server via your proxy (which probably doesn't work, depending on your setup).
Darylrese Posted November 29, 2012 Author Posted November 29, 2012 Nope, heres our proxy settings GPO, do i need to make changes to this?
Mcshammer_dj Posted November 29, 2012 Posted November 29, 2012 Try doing this: To reset the Windows Update components, follow these steps: 1.Open a Windows Command Prompt Windows. To open a command prompt, click Start and then click Run. Copy and paste (or type) the following command in the Open box and then press ENTER: cmd 2.Stop the BITS service and the Windows Update service. To do this, type the following commands at a command prompt. Press ENTER after you type each command. ◦net stop bits ◦net stop wuauserv 3.Delete the qmgr*.dat files. To do this, type the following command at a command prompt, and then press ENTER: Del "%ALLUSERSPROFILE%\Application Data\Microsoft\Network\Downloader\qmgr*.dat" 4.If this is your first attempt at resolving your Windows Update issues by using the steps in this article, go to step 5 without carrying out step 4. Step 4 should only be performed at this point in the troubleshooting if you cannot resolve your Windows Update issues after following all steps but step 4. The steps in step 4 are also performed by the "Aggressive" mode of the Fix it Solution above: a.Rename the following folders to *.BAK: ■%systemroot%\SoftwareDistribution\DataStore ■%systemroot%\SoftwareDistribution\Download ■%systemroot%\system32\catroot2 To do this, type the following commands at a command prompt. Press ENTER after you type each command. ■Ren %systemroot%\SoftwareDistribution\DataStore *.bak ■Ren %systemroot%\SoftwareDistribution\Download *.bak ■Ren %systemroot%\system32\catroot2 *.bak b.Reset the BITS service and the Windows Update service to the default security descriptor. To do this, type the following commands at a command prompt. Press ENTER after you type each command. ■sc.exe sdset bits D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU) ■sc.exe sdset wuauserv D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU) 5.Type the following command at a command prompt, and then press ENTER: cd /d %windir%\system32 6.Reregister the BITS files and the Windows Update files. To do this, type the following commands at a command prompt. Press ENTER after you type each command. ◦regsvr32.exe atl.dll ◦regsvr32.exe urlmon.dll ◦regsvr32.exe mshtml.dll ◦regsvr32.exe shdocvw.dll ◦regsvr32.exe browseui.dll ◦regsvr32.exe jscript.dll ◦regsvr32.exe vbscript.dll ◦regsvr32.exe scrrun.dll ◦regsvr32.exe msxml.dll ◦regsvr32.exe msxml3.dll ◦regsvr32.exe msxml6.dll ◦regsvr32.exe actxprxy.dll ◦regsvr32.exe softpub.dll ◦regsvr32.exe wintrust.dll ◦regsvr32.exe dssenh.dll ◦regsvr32.exe rsaenh.dll ◦regsvr32.exe gpkcsp.dll ◦regsvr32.exe sccbase.dll ◦regsvr32.exe slbcsp.dll ◦regsvr32.exe cryptdlg.dll ◦regsvr32.exe oleaut32.dll ◦regsvr32.exe ole32.dll ◦regsvr32.exe shell32.dll ◦regsvr32.exe initpki.dll ◦regsvr32.exe wuapi.dll ◦regsvr32.exe wuaueng.dll ◦regsvr32.exe wuaueng1.dll ◦regsvr32.exe wucltui.dll ◦regsvr32.exe wups.dll ◦regsvr32.exe wups2.dll ◦regsvr32.exe wuweb.dll ◦regsvr32.exe qmgr.dll ◦regsvr32.exe qmgrprxy.dll ◦regsvr32.exe wucltux.dll ◦regsvr32.exe muweb.dll ◦regsvr32.exe wuwebv.dll 7.Reset Winsock. To do this, type the following command at a command prompt, and then press ENTER: netsh reset winsock 8.If you are running Windows XP or Windows Server 2003, you have to set the proxy settings. To do this, type the following command at a command prompt, and then press ENTER: proxycfg.exe -d 9.Restart the BITS service and the Windows Update service. To do this, type the following commands at a command prompt. Press ENTER after you type each command. ◦net start bits ◦net start wuauserv 10.If you are running Windows Vista or Windows Server 2008, clear the BITS queue. To do this, type the following command at a command prompt, and then press ENTER: bitsadmin.exe /reset /allusers 11.Install the latest Windows Update Agent. For more information, click the following article number to view the article in the Microsoft Knowledge Base: 949104 (How to get the latest version of the Windows Update Agent ) How to obtain the latest version of the Windows Update Agent to help manage updates on a computer 12.Restart the computer.
alan-d Posted November 29, 2012 Posted November 29, 2012 (edited) Try running this on a client not being picked up @echo Setting winhttp proxy netsh winhttp set proxy SERVERNAME:8530 "10.*" @echo Triggering detection after setting winhttp proxy net stop wuauserv net start wuauserv wuauclt /resetauthorization /detectnow A restart may be needed. If it works, save the above as a .bat and stick it in a GPO. Edited November 29, 2012 by alan-d
Darylrese Posted November 29, 2012 Author Posted November 29, 2012 there are 2 clients that are reporting to WSUS and recieving updates, one server and one workstation. Checked and the proxy settings on those 2 are the same as the others on the network that arnt working
Darylrese Posted November 29, 2012 Author Posted November 29, 2012 (edited) Try running this on a client not being picked up @echo Setting winhttp proxy netsh winhttp set proxy SERVERNAME:8530 "10.*" @echo Triggering detection after setting winhttp proxy net stop wuauserv net start wuauserv wuauclt /resetauthorization /detectnow A restart may be needed. If it works, save the above as a .bat and stick it in a GPO. Many thanks, will try this script now. In the line netsh winhttp set proxy SERVERNAME:8530 "10.*" is this the proxy server for sername or wsus server? Ive tried it as netsh winhttp set proxy 10.160.2.6:8080 "10.*" (which is our proxy server) but it says access denied EDIT: Not to worry, it has to be elevated to run as administrator. Should this now pull down updates as soon as the script has finnished? Edited November 29, 2012 by Darylrese
Ergo Posted November 29, 2012 Posted November 29, 2012 (edited) Should this now pull down updates as soon as the script has finnished? Yes. the last line triggers the Windows Update service on the client to start scanning - can take a few minutes though. If you are running this on a machine which has already registered with the WSUS server you may be better to change the last line to: wuauclt /detectnow This will reduce the likelyhood of duplicates in the WSUS console. Dave Edited November 29, 2012 by Ergo
Darylrese Posted November 29, 2012 Author Posted November 29, 2012 (edited) Thanks as always Dave! Cheers for the script alan. I am getting the following error in event viewer still: I tried it on the one workstation that is reporting and working with WSUS and its given the same error Edited November 29, 2012 by Darylrese
Ergo Posted November 29, 2012 Posted November 29, 2012 Daryl, I cannot see the GPO you have deploying WSUS settings to the client (looks like edugeek forum has lost the picture?) so if you could send the settings would be useful. I would recommend explicitly putting an exception for the WSUS server (name or IP depending on how you have specified it) in your proxy settings. Also important to ensure you have populated both settings (server address and reporting address). Also there is a Windows Update log file which is in C:\Windows\WindowsUpdate.log so it would be useful to look in there for more detailed error information. I would not recommend posting the whole file as it can get quite big! Dave
Darylrese Posted November 29, 2012 Author Posted November 29, 2012 Sorry about that Dave, it seems to have gone missing! Here it is again:
Michael Posted November 29, 2012 Posted November 29, 2012 Hmm maybe I'm missing something here. Looking at the first screenshot, workstations are reporting in but they're just reporting 0%. I presume if you delete a computer from WSUS, it then re-appears after a while? This would prove workstations reporting in is OK. I suspect the problem is with your WSUS server somewhere, seeing as everything is reading 0%. If you follow my userguide here, it may give you some ideas what's going on.
Darylrese Posted November 29, 2012 Author Posted November 29, 2012 Nope, they all display as 'Not yet Reported' so i dont think they are reporting atall
Darylrese Posted November 29, 2012 Author Posted November 29, 2012 (edited) 2 of our servers are updating also but only 2 Edited November 29, 2012 by Darylrese
Michael Posted November 29, 2012 Posted November 29, 2012 Nope, they all display as 'Not yet Reported' so i dont think they are reporting atall [ATTACH=CONFIG]16118[/ATTACH] What I meant was they've reported to the WSUS console itself. That column simply means workstations haven't reported their patch status i.e how many's been installed.
Ergo Posted November 29, 2012 Posted November 29, 2012 Daryl, Any chance of you getting the windowsupdate.log file from one of the client machines which is NOT reporting? Dave
alan-d Posted November 29, 2012 Posted November 29, 2012 Many thanks, will try this script now. In the line netsh winhttp set proxy SERVERNAME:8530 "10.*" is this the proxy server for sername or wsus server? Ive tried it as netsh winhttp set proxy 10.160.2.6:8080 "10.*" (which is our proxy server) but it says access denied EDIT: Not to worry, it has to be elevated to run as administrator. Should this now pull down updates as soon as the script has finnished? Just to clarify - SERVERNAME should be your WSUS server and the port should be what WSUS is using.
Darylrese Posted November 30, 2012 Author Posted November 30, 2012 CHEERS, ive replaced it with 10.160.2.6:80 as the port is 80. What do i change the "10.* to?
LawrenceGarvin Posted December 7, 2012 Posted December 7, 2012 Actually, based on the fact that all of the updates have NO STATUS, they're not even TALKING to the WSUS server. They are "registered", so that tells us that your GPO and Proxy configurations are correct, but now the question is why are they not talking. Inasmuch as your WSUS server has only been running "for a few weeks now", the most likely case here is that your WSUS clients, which probably were AU clients previously, were updated with the new Windows Update Agent in June, 2012. But your WSUS server, being new, probably does not have the KB2720211 patch applied, which is required so that the June, 2012, WUAgent (v7.6) can successfully detect/report to the WSUS server. This situation will be evidenced by the presence of the 0x800B0001 error code in the WindowsUpdate.log of each client system.
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now