SQL Server 2008 Version Numbers

What this check looks for

The build number from SERVERPROPERTY('ProductVersion'), compared against the latest service pack, cumulative update and security patch known for that major version. The check parses the revision portion of the build and reports when it is behind.

Why it matters

A SQL Server build number is the only honest statement of which fixes the instance has. Everything else is recollection.

There are three separate reasons a build falls behind, and they call for different urgency:

Security fixes. These are the ones with a deadline attached. A patched vulnerability is a published vulnerability, so the gap between release and application is a window where the details are known and the instance is not protected.

Correctness fixes. Cumulative updates routinely contain fixes for incorrect query results, for corruption introduced by particular operations, and for crashes under specific conditions. These are the fixes people discover they needed retrospectively, after spending a week chasing something that was already fixed.

Performance and behavior fixes. Cardinality estimation, spinlock behavior, scheduler fairness. Less urgent, and often the quiet reason an instance behaves better after patching.

Out of support is the harder version of the problem. A major version past its extended support date receives nothing at all, including security fixes, regardless of how diligently you patch. At that point the fix is an upgrade, not an update, and it is a project.

What actually blocks this in practice is not the patch, it is the window. Applying a cumulative update is typically fifteen to thirty minutes of downtime, and arranging those thirty minutes is what takes most of the estimate. That is worth naming, because the reason instances fall years behind is rarely that anybody decided not to patch.

How to confirm it yourself

Exactly what you are running:

SELECT SERVERPROPERTY('ProductVersion')      AS [build],
       SERVERPROPERTY('ProductLevel')        AS [service_pack],
       SERVERPROPERTY('ProductUpdateLevel')  AS [cu_level],
       SERVERPROPERTY('ProductMajorVersion') AS [major],
       SERVERPROPERTY('Edition')             AS [edition],
       SERVERPROPERTY('ProductBuildType')    AS [build_type],
       @@VERSION                             AS [full_version];

ProductUpdateLevel is the direct answer on SQL Server 2012 and later; it returns the CU name, or NULL if none has been applied on top of the current service pack.

Compare the build against the vendor list, not against memory. Microsoft publishes the current build for every supported version, and that page is the authority for whether this finding is correct today.

And the practical question, how long the instance has been up, since patching requires taking that away:

SELECT [sqlserver_start_time],
       DATEDIFF(DAY, [sqlserver_start_time], GETDATE()) AS [days_up]
  FROM sys.dm_os_sys_info WITH (NOLOCK);

Check every instance, not just this one. Version drift across an estate is what makes a failover land on an older build than the one that was being tested.

How to fix it

Apply the latest cumulative update for the major version you are on. Test it somewhere first, and take a backup.

1. Establish the target. Find the current build for your major version and read the fix list for what is between you and it. If a specific fix is the reason, note it; it makes the change request easier to justify.
2. Check supportability. If the major version is out of extended support, patching is not available and the real item is an upgrade.
3. Apply it in a lower environment first, on the same build you are moving from, and run the application’s normal cycle against it.
4. Back up first, including master and msdb, and confirm the backups restore.
5. Plan the window. Typically fifteen to thirty minutes for a standalone instance. On an availability group or a failover cluster it is longer and needs an order: patch the secondary, fail over, patch the old primary.
6. Apply, restart, and verify:

SELECT SERVERPROPERTY('ProductVersion')    AS [build_now],
       SERVERPROPERTY('ProductUpdateLevel') AS [cu_now];

7. Check the error log after the restart for anything the upgrade recorded, and confirm the databases are all online:

SELECT [name], [state_desc], [compatibility_level], [is_read_only]
  FROM sys.databases WITH (NOLOCK)
 ORDER BY [database_id];

Patch on a schedule rather than on a finding. Quarterly is a common and defensible cadence for cumulative updates, with security updates taken sooner. The instances that end up years behind are the ones patched only when somebody notices.

Note that a cumulative update does not change compatibility level, so the optimizer behavior your application depends on does not change underneath you. That is a common and unfounded fear about CUs specifically.

How long it takes

About three hours including testing and the change process. The installation itself is typically fifteen to thirty minutes of downtime.

Related reports

Related checks

Frequently asked questions

Do I have to take every cumulative update? Microsoft recommends CUs be applied proactively, at the same confidence level as service packs. A quarterly cadence catches everything without chasing each release.

Will a CU change my query plans? Compatibility level governs the optimizer model, and a CU does not change it. Some fixes do change behavior, which is why you test, but the usual fear of wholesale plan regression from a CU is misplaced.

The build looks current to me. Check the vendor build list for today. The check compares against the latest build known when it was written, so a very new release can also produce a stale comparison in the other direction.

We cannot get a maintenance window. That is the real finding, and it is worth raising as such. An instance that can never be taken down for thirty minutes also cannot be failed over, restarted or recovered on a schedule, which is a larger problem than the missing patch.