WSUS versions can be a sticky subject. Here's a super-short primer:
WSUS 3.0 (SP2) + KB2720211 = Build 3.2.7600.251
WSUS 3.0 (SP2) + KB2734608 = Build 3.2.7600.256
WSUS 3.0 (SP2) + KB2828185 = Build 3.2.7600.262
You should most definitely reboot your WSUS Server after these patches have been applied. If you are still having issues, go ahead and post back. We'll be sure to look at it.
It's definitely been rebooted. It's just sad that Microsoft can't fix something as simple as Help | About.
However, if I click Help | About Update Services... it reports the version as 3.2.7600.226!
This question is addressed in SolarWinds KB4107.
Your server IS at build 262 (KB28281815 is installed).
Which still leaves us with the question of why your clients are not communicating.
The diagnostics for this will be found in the WindowsUpdate.log of a failing client.
Most notably, if these clients just became WSUS clients recently, they may have been updated to a YET NEWER Windows Update Agent via WU/MU, which will require that you install KB2938066 to the WSUS servers and PM servers. But before you do that, let's confirm with the WindowsUpdate.log
I have posted two WindowsUpdate.log files here. These are both for POS terminals that do not have a connection to the Internet. 015POSTERM3 last reported in to the WSUS server on 8/20/2014. 015POSTERM6 reported in to WSUS this morning around 7:30 am Eastern (I have only included the last 4 days of WindowsUpdate in this log file for brevity). There does not seem to be a noticeable difference between the two log files. The terminals are Windows 7 Pro Embedded and were built using the same image, and are the same hardware.
If you can find the clue that gets me in the right direction for resolution you'd be a rock star in my book.
The logfile from 015POSTERM3 only includes a single detection event, combined with a service start/stop, at 8:30am this morning, but the most notable thing is this oft-seen error:
2014-09-10 08:32:59:402 4004 eb4 PT Initializing simple targeting cookie, clientId = b97d90e4-9d1b-48b3-afac-bb6502e5c9e8, target group = , DNS name = 015posterm3
2014-09-10 08:32:59:402 4004 eb4 PT Server URL = http://192.168.254.54/SimpleAuthWebService/SimpleAuth.asmx
2014-09-10 08:32:59:496 4004 eb4 PT WARNING: GetCookie failure, error = 0x8024400D, soap client error = 7, soap error code = 300, HTTP status code = 200
2014-09-10 08:32:59:496 4004 eb4 PT WARNING: SOAP Fault: 0x00012c
2014-09-10 08:32:59:496 4004 eb4 PT WARNING: faultstring:Fault occurred
2014-09-10 08:32:59:496 4004 eb4 PT WARNING: ErrorCode:ServerChanged(4)
2014-09-10 08:32:59:496 4004 eb4 PT WARNING: Message:Server rolled back since last call to GetCookie
2014-09-10 08:32:59:496 4004 eb4 PT WARNING: Method:"http://www.microsoft.com/SoftwareDistribution/Server/ClientWebService/GetCookie"
2014-09-10 08:32:59:496 4004 eb4 PT WARNING: ID:451f2d05-6493-4ef3-acdd-9518a98d7278
2014-09-10 08:32:59:496 4004 eb4 PT WARNING: PTError: 0x80244015
2014-09-10 08:32:59:496 4004 eb4 PT WARNING: GetCookie_WithRecovery failed : 0x80244015
2014-09-10 08:32:59:496 4004 eb4 PT WARNING: RefreshCookie failed: 0x80244015
2014-09-10 08:32:59:496 4004 eb4 PT WARNING: RefreshPTState failed: 0x80244015
2014-09-10 08:32:59:496 4004 eb4 PT WARNING: Sync of Updates: 0x80244015
This sequence is quite commonly associated with a duplicate SusClientID issue, but I've also seen it sporadically occur when a client is talking to a replica server. Having additional activity in the logfile could show a more complete picture.
In the 015POSTERM6 logfile, which gives us a few days of history, we see normal operations until 8:30pm on the evening of Sept 7th, at which time the client encounters a collection of updates which, ostensibly, have defective metadata. In short, the detection appears to have failed with the error code 0x8007000E
2014-09-07 20:31:16:133 744 6a0 Agent * WARNING: Exit code = 0x8007000E
This is an OUT_OF_MEMORY error, suggesting that it's a client-side error. It could be a function of a corrupted datastore, or it could be a full volume precluding expansion of the paging file.
Unfortunately 015POSTERM6 is checking in -- and receiving updates, at least according to the Windows Updates applied as shown in Control Panel -- correctly. In this case 015POSTERM3 is the one that won't report in. I've deleted the SusClientID keys from both workstations and forced a /resetauthorization and /detectnow. TERM3 still refuses to check in and report.
Okay.. good that '6' is checking in and receiving updates, but there's still an issue on that terminal that probably needs to be investigated.
As for '3', if you can get me a more complete logfile than initially provided, I can possibly make a more accurate analysis.
Also worthy of note, '3' is logging the same 0x8007000E OUT_OF_MEMORY errors.
Attached is the previous WindowsUpdate log for TERM3.
I've noticed the 8007000E errors on all of my POS terminals (70 stores * average of 10 terminals per store) but since most of them are checking in I haven't bothered to run down the cause of the error yet. The problem with terminals not reporting to the WSUS server has been going on longer than I've been employed here and this problem was just recently dumped into my lap, so my first priority has been to get them to check in.