A new update appears before the last change ticket is closed. Staying current means choosing a steady rhythm, while security fixes get a faster route.
Make Staying Current a Boring Cadence
A policy works when the team can repeat it. Choose a regular review point for CU release notes and a regular test window. Production follows after a representative application test. This way of staying current is easier to run than a promise to install every CU the day it arrives. The newest package can appear while your current test is still in progress.
I prefer an approved target build per major release. That target changes only after review, testing, and a scheduled rollout. The inventory then has a clear answer for every instance: at target, behind target, or on a documented exception. No one needs to guess what “current” means during an audit.
How long can your team leave a known fix untested? Ask that when setting the cadence. A schedule that exceeds your support and security needs is neat on paper and weak in practice.
Use One CU Behind Deliberately
Some teams choose to run one CU behind the newest available release. That gives the latest CU time for field feedback while avoiding a long backlog. It is a policy choice, not a magic safety rule. A newer CU can contain a fix your workload urgently needs. A known issue in the previous CU can also change the choice.
Write the rule with an exception path. The policy can say routine rollout targets the previous approved CU, while a critical fix can move faster after focused testing. Record why the exception exists and which applications it covers. The same rule should not be applied blindly to every server.
I have seen teams announce “one CU behind” and then discover three years of drift. Check the full ProductVersion. The friendly CU label alone can hide a later GDR or an on demand build.
SELECT
@@SERVERNAME AS ConnectedInstance,
SERVERPROPERTY('ProductVersion') AS ProductVersion,
SERVERPROPERTY('ProductUpdateLevel') AS UpdateLevel,
SERVERPROPERTY('ProductBuildType') AS BuildType;Give Security Its Own Clock
A security bulletin does not wait for your routine CU calendar. Read the affected build range and exploit conditions. Inventory exposed instances and choose the correct security package for their servicing branch. Test the affected application paths quickly, then patch in risk order.
Do not translate “fast” into “blind.” Verify backups, choose an order for availability replicas, and set a stop rule. The security team should know which servers are patched, which are mitigated, and which are still unverified. Those are different states.
Keep temporary controls visible. Isolation can reduce exposure while testing finishes. It does not make an unpatched build current. Give the control an owner and an expiry date.
Keep an Accurate Target Table for Staying Current
Create a small target record for each supported major version and application group. Store the approved full build, update label, approval date, and next review date. If an application needs a temporary exception, record its owner and expected end. A target without a date becomes a museum label.
Capture each instance’s build on a schedule. Include the last successful capture time in reports. A server that stopped reporting should not inherit yesterday’s green status. Connect directly to every availability replica. A listener only shows the current primary.
For a quick local check, the version query is enough. For fleet decisions, use a dated history table and map each full build to the official release history. Sorting version strings as text can give the wrong answer.
Test the Workload That Matters
A routine CU test should restore current data and run key jobs, reports, and application transactions. Check error logs and backup behavior. Compare plans and measured timings for critical queries. The test does not need to explore every feature, but it needs to cover the features you use.
If a CU fixes a problem you have, reproduce the problem before patching. Then rerun the same check. If the release notes describe a known issue near your workload, add a focused test. Do not approve the package because installation alone succeeded.
Keep the exact package in the test record. A newer package downloaded on patch day is a new change. A calendar slot does not approve new bits by itself.
Stage the Rollout
Start with a test instance, then a small production group, then the rest of the fleet. Watch the first group long enough to catch job cycles and application paths that the lab missed. Pause if a new error appears. A staged rollout creates a useful stop point.
Schedule availability group members in the documented order. Patch secondaries, verify synchronization, fail over, then patch the former primary. Coordinate backups and scheduled jobs. A fleet script that patches machines alphabetically is a fine way to learn the alphabet and a poor way to preserve service.
Check the target build after each install and read Setup’s summary. The patch count is based on verified running instances, not installer starts.
SELECT d.name AS DatabaseName,
MAX(b.backup_finish_date) AS LastFullBackup
FROM sys.databases AS d
LEFT JOIN msdb.dbo.backupset AS b
ON b.database_name = d.name
AND b.type = 'D'
WHERE d.database_id > 4
GROUP BY d.name
ORDER BY d.name;Review the Staying Current Policy With Evidence
Each cycle should show how many instances are at the approved target, how many are behind, and why. Use actual inventory counts. Add missed captures and exceptions to the same report. If the team repeatedly misses its own window, change the policy or the resources. Do not keep an impossible promise for decoration.
I review incidents against the patch history. Was a fix already available? Did the server skip a maintenance window? Did the test miss a job? Those answers improve the cadence. They also make the next security response less frantic.
A good patch policy is short enough to explain over coffee and strong enough to survive a busy month. Routine updates follow a rhythm. Security gets immediate attention. Every exception has a date.
Related reading on this blog: Patch Your SQL Server: SQL in Sixty Seconds #100 and How to Apply Patch in AlwaysOn Availability Group Configuration?.
Staying current is not chasing every package, it is keeping a schedule you can prove.
Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.
