There's a fun indicator you can use to quickly evaluate whether you've been missing security updates for the last five years (ish) on older Operating Systems (i.e. Win2008-2008 R2), and it's the build number. Not infallible, but then not often wrong.
Back In The Day, Build Numbers Were Even More Useful
Very helpfully, the Windows Vista era introduced incremental build numbers for Operating System versions. So when it shipped, Windows Vista - which you'll recall came out almost a year ahead of the server equivalent, Windows Server 2008 - shipped with the build number 6000.
Windows Server 2008 shipped with "Windows Vista" Service Pack 1 inbuilt, as it were, and so Vista and Windows Server 2008 SP1 have the same build number, 6001.
Service Pack 2 followed, again incrementing the build number to 6002.
For the Windows 7 era, things were a bit more straightforward. Windows 7 and Windows Server 2008 R2 shipped at about the same time, as build 7600.
When Service Pack 1 was released for both, the build number incremented to 7601.
Quite a few of our Premier Security Assessments pull OS information using WMI from targets, and I sort by the reported build number to quickly identify groups of hosts which might not have a Service Pack. It's very, very infrequently wrong. You could equally do the same by whether "Service Pack X" appears in the CSDVersion, but the build number is a nice, straightforward way of identifying this if you're collecting it widely.
(AD Computer objects track what appears to be the same information, so querying AD might be a viable option if you're reasonably certain that the computer objects there are still "live").
What can you do with this information?
Well, you can say for sure that anything which self-reports as being build 7600 - i.e. not 7601 - probably hasn't had any Windows security updates since about 2013.
The Support Lifecycle site notes that without SP1, Windows Server 2008 R2 (7600) exited support in April 2013. That's the point after which security updates stop applying, because they require SP1 (7601), which isn't installed.
Likewise, if you've a Windows Server 2008 (6001) Server, it hit End Of Support at the same time (and Service Pack 2 (6002) is required for any updates beyond that point).
If you haven't got the relevant Service Pack approved in WSUS (or SCCM), the computers won't even see updates beyond this point as being applicable. So it might seem like you've a bunch of completely updated and compliant servers, (on closer inspection finding lots of updates aren't applicable to them) but if they haven't taken the Service Pack, they're only as updated as they self-report. And they know the newer updates aren't for them.
In this case, "newer" means "pretty much everything since mid 2013"
What should you do?
So here's what to do: Pull a report of the OS versions reported by servers within your environment. Clients too, if you think it's possible some don't have Win7 SP1.
You could do something like:
- PS: get-adcomputer -Filter '(OperatingSystemVersion -like "*7600*") -or (OperatingSystemV
ersion -like "*6001*")' -Properties OperatingSystemVersion,OperatingSystemServicePack | export-csv NoServicePack.csv- (Blank NoServicePack.csv = good)
- WSUS: Turn on the Version column in the Computers view in the WSUS console, then Group By (or just Sort by) Version and look at the build numbers reported.
If there are 7600s or 6001s found, check a few out, and just confirm that they're not relevant-Service-Pack-less. If they are, try to work out and address the root cause - for eg, the Service Pack update wasn't approved, or the WSUS catalog doesn't include the update, or the PC isn't in the right SCCM update group, or... whatever it is.
As a note, if you're in that bucket, you're likely to have many updates to apply, which will likely take some time and disk space to chew through. (If it's simpler to redeploy an OS with a current build than update an older one, consider that).
And
And if you've found some unpatched boxes as a result of reading this, a) phew, lucky we found them now, and b) really think about that root cause. Mistakes are inevitable; does your process allow for mistakes and have any built-in correction for them? Update management isn't always easy, but many update policies are geared towards fragility and failure, due to excessive process being required for an update to make it to the target box. A process failure without a corrective phase might result in updates being missed for years.
In some cases, what we hear is that some set of updates are initially rejected (or "deferred") due to issues or concerns, which is fair enough - but then the decision doesn't get revisited for months or years afterwards - sometimes never, until the update state is compared with Windows Update. If you don't look back and check your assumptions - really test what updates are deployed and what you're still vulnerable to - then things can rapidly and near-invisibly deteriorate, until suddenly, one day you're looking back at 5 years of unpatched systems.
Core question: If the participants in your existing update process/policy had been pointed directly at Windows Update and set to update weekly, how many Critical and Important updates might have been applied in the interim?
And And: an afterthought for 2012 R2
I haven't got into 2919355 yet, but it's the 2012 R2 (and Windows 8.1) equivalent of a Service Pack, and as of late 2014, it became the mandatory update on which all other 2012 R2 (and 8.1) updates depended. Unfortunately, I don't think it's a simple build check for that one (though it might be visible though the detailed build reported by the WSUS console - I don't have one to check right now), but it's the other key update we find missing when evaluating update state.