KevinH

The 4010 is a "better" error to have as it is typically transient and almost expected if you deleted the softwaredistribution folder with the typical "nuke and pave" client reset script. Have you run WU (hitting your WSUS server) several times on a 4010 machine manually - even though it fails, it should be building a cache and adding to it at each failure?

He goes by OverDrive on Spiceworks, and his script is all that! Some people hesitate (mine was already running OK), but the approvals process just flies after you run it. Takes out the rubbish, and re-indexes the tables. Watch the next time you approve updates, it will shock you how fast it runs.

That's interesting, and a new one on me. Never saw WMIC conputersystem get model fail - but I'll take your word for it. BTW - Dell has changed the format of WMIC names recently, so if you get new Dell kit, be sure to run the command on them. Was reported over on Spiceworks when a guy couldn't get drivers to inject on a new series recently. My first two Lenovos broke MDT when a few of my Dells decided they liked a Lenovo video driver better than the Intel one a few years back, went total control the very next week. That was an ugly scene ...

Reported to work WSUSPool advanced settings Set WSUSPool private memory limit to 0 (no limit) Regular time interval to 0 (no "arbitrary" schedule) Set specific time to 4AM so it recycles when no one's around. Coffee time!

The MDT driver management bible: Deployment Research > Research

Have you tried temporarily disabling sophos on a client that's playing up? Endpoint security apps have borked WU/WSUS more than once. An examination of the firewall logs may show it blocking stuff at the time the client is trying to update.

Nowhere in the discussion has malware been mentioned - have you run Malwarebytes or SuperAnti on any of the clients that dont update? If you havent already, the System Update readiness tool I mentioned upthread would also be a good idea as it tends to root out corruption in the stack.

By any chance is there an SCCM install somewhere on this network?

Have you run SURT on a client? https://support.microsoft.com/en-us/kb/947821 Almost all the hits for that error refer to an update (Office 2K3 SP1) being in an inconsistent approval state. Supposedly fixed by a WSUS 3 Service pack, but won't hurt anything to check that it's either absent or declined for all WSUS groups (KB842532) Ancient, unlikely, and you've probably already covered it. Revisiting the error, it suggests a bad XML file for an update causing the server to not be able to respond with a valid update list - if neither of the two comments above are productive, my next thought would be to run a wsusutil /reset (when you're ready to leave for the day, it would be like watching a lake freeze) and try again in the morning.

Since we're back to 2008 again - post up a log of a current detect off one of the clients. This is very odd - not that you didn't know that ...

Thinking more about ways to isolate this: Can you create a GPO for a test OU and try setting the WSUS server to dotted decimal IP? It may do nothing - but easily undone and then you can rule out DNS. Be sure it's in the right place in the GPO structure to "win" and verify with RSOP. A ways upthread, it was suggested to run proxycfg - and ruling out your proxy server trashing winhttp would also be progress. You need to rule stuff out here - knowing what it isn't is an important step to finding out what it is

If you haven't flattened the 2012 install yet - I would run OverDrive's maintenance script on it. Think of it as the server cleanup wizard on steroids. It really works - reindexes the WSUS database and sped up the approvals process on a working unit by orders of magnitude. Right now, it's a nothing to lose scenario - once you get past the rest node issue, the latest WSUS does work quite well. https://community.spiceworks.com/topic/1264229-wsus-console-crashing

What does your products and classifications list look like? All is bad news, as every client then has to check every single update MS ever made, which makes the query God-awful and can throw timeouts as a result. That list is best kept well-pruned. And if you have drivers selected, that would be the first item I would take off the list.

You HAD a perfectly functioning WSUS - then virtualized it. I'm not trying to be cheeky - just highlighting the change event that broke your universe. Not knowing what platform you're using and how you set it up, here's what I'd look at. Be sure the WSUS VM retained its static address through the P2V process. Look in the adapter properties on the guest and be sure what you're seeing makes sense. Be sure you gave it enough CPU/RAM resources to handle the number of clients you have. Task manager on the guest will show if either CPU or RAM are overtaxed. SQL is a RAM hog - and if you're tight to the top, it's going to have to page - not good on queries that are timeout governed. My WSUS is on a physical box but I do have 3 VMs in hyper-v hanging off a different server. If the host has adequate NICs to do so, I would not allow the host to share the WSUS machine's NIC, but I have that option because that particular host has 6 NICs and the host won't get cut off from the world by doing it. Depending on your GPO structure, it wouldn't be a bad idea to take a single (smaller) OU and set the WSUS GPO to the dotted decimal IP address of the WSUS server rather than the name (taking DNS resolution out of the picture) Apologies for the replies not really fitting your schedule - but I've been on the wrong side of the clock so what you're seeing me post with your morning coffee I'm posting at 2AM and right now I'm having my morning coffee.

I'd also run nslookup for the WSUS server name on a functioning client and a broken one - just to rule out DNS, which has broken a WSUS or 3.

Check the server for KB3148812 and/or KB3159706 also and check if either or both are installed. If you have either/both, post back which one/s, if you completed the post-install configuration steps, and if you modified the web.config file. Trying to avoid writing an essay - but if you didn't do the post-install or modify the web.config, and you don't currently have windows 10 clients - I would remove the update(s) and hide them for now. If you did the post-install and the web.config edits, different kettle of fish.

Did you bump up the private memory limit for wsuspool, also check to be sure wsuspool is not in a stopped state. All those errors go back to 503 - service unavailable How much RAM did you give the VM?

You've been back and forth on a lot of things - so it may help to go over the basics of where things are at now. Server OS? WSUS build number? Error code being thrown? Can you post a (sterilized) Windowsupdate.log - just the last complete run off one of the problem children -should shed some light on the subject - doesn't make sense that identical hardware, that I take it is on the same VLAN, one works and the one next to it doesn't.

This may help some of you, or none of you, but probably worth a look. Windows Update Error 80072ee2 (WSUS) - Scott Breen The author has run into WSUSPool memory exhaustion as an issue - perhaps a peek at the relevant logs on the server is in order?

WSUS on 2012 requires a GPO change from http://wsuservername to http://wsuservername:8530 as the port is different On the 2012 server, two updates (3148812 and its replacement 3159706) broke WSUS in dramatic fashion, see second post on this page. https://community.spiceworks.com/topic/1567653-heads-up-kb3148812-for-wsus-servers-and-replacement-kb3159706?page=5

Create a security group, add that user to it, and place a deny on the GPO for that group. How to exclude individual users or computers from a Group Policy Object

My current setup is a Windows domain using Trend's WFBS as a filtering solution and it has served admirably. However, the closing of another school has made me the recipient of a dozen Chromebooks and 30 IPads, and to make them actually useful and keep the little inmates from going bad places I need a more comprehensive filtering solution before I put them out in the wild. Server horsepower is available, so I prefer an on-premise solution, and as always, money is tight to non-existent. Your collective wisdom is appreciated. Thanks

State Restore failures are no fun - and the one case where server-side logging really doesn't help because the last entry in the server log is "restarting" ... The BDD.log file off the client should tell you where it failed, should be in C:\MININT\SMSOSD\OSDLOGS Grab a copy of CMTRACE (free) from MS, it parses the log files into human-readable form and flags warnings and errors in red and yellow to call them out for you. Two things off the top of my head that would stop it cold are failing to re-connect to the share and getting dropped into an OU where script execution is blocked by GPO - entirely different essays! (Edit) Walked away mid-post and see James wrote pretty much the same thing before I finished

Monitoring is good, but I prefer server-side logging as described here: https://www.brandonlawson.com/deployment/when-mdt-starts-breaking-bad/ Basically MDT keeps a running copy of the deployment logs on your share in real-time. Then you can run CMTrace against the log file to narrow it down pretty quickly. Is the task sequence stalling out installing a particular application?

If you never plan to have WSUS handle Win10 updates ever again, then killing the update is fine. The problem with the update is that it does require manual configuration after the install, and like all MS documentation, the instructions are in Martian. The human version is here: https://community.spiceworks.com/topic/1567653-heads-up-kb3148812-for-wsus-servers?page=5#entry-5795194 If you aren't running 10 now, fine - but if you add it later - you will be revisiting this update soon enough.