Every SQL Server instance is on one of two servicing paths, whether anybody chose it or not. GDR or CU is that choice: the security focused GDR path, or the cumulative update path that carries every fix.
Understand the Two Paths: GDR or CU
A general distribution release, or GDR, addresses issues with broad impact, security implications, or both. A cumulative update, or CU, includes fixes and improvements released for that SQL Server version since its baseline. Microsoft documents the package content for each release. Read the exact note before assigning it a label.
When I ask which path a server is on, the most common answer is a guess. The second most common is that nobody ever decided.
A team that stays on a GDR path typically wants the narrower set of broadly distributed fixes. A team that installs CUs receives the larger cumulative fix set. Neither path means “never test.” Security updates and CUs both change production binaries.
The branch is part of your maintenance policy. Record why an application is on it. A server drifting between branches without a plan is harder to support than one following a deliberate, tested cadence.
Read the Full Build
ProductVersion is the precise version string. ProductUpdateLevel gives a CU label when applicable. ProductBuildType can identify a GDR or on demand build. A NULL label does not prove that no update is installed. Use the official SQL Server version history to map the full build to a release entry.
A GDR can sit on an RTM baseline or on a CU baseline. Two instances can share a CU label yet have different full builds because one received a later GDR. Compare the whole ProductVersion and the documented branch, not just the friendly label.
Collect the version from each instance directly. An availability group listener can show only its current primary. A host can contain several instances. Your branch report needs one row for every actual Database Engine installation.
SELECT
@@SERVERNAME AS ConnectedInstance,
SERVERPROPERTY('ProductVersion') AS ProductVersion,
SERVERPROPERTY('ProductLevel') AS ProductLevel,
SERVERPROPERTY('ProductUpdateLevel') AS UpdateLevel,
SERVERPROPERTY('ProductBuildType') AS BuildType;The server will tell you which path it is on, if you ask for the right properties.
SELECT
SERVERPROPERTY('ProductVersion') AS ProductVersion,
SERVERPROPERTY('ProductUpdateLevel') AS UpdateLevel,
SERVERPROPERTY('ProductBuildType') AS BuildType,
SERVERPROPERTY('ProductUpdateReference') AS KbArticle;Choose GDR or CU Based on Your Workload
Read the fix list for the current CU. If your workload has a known defect addressed there, that is a concrete reason to evaluate the CU path. If your policy limits routine changes and your current build has no relevant defect, a GDR path can be a deliberate choice, subject to your support and security requirements.
Almost every server I find on the GDR branch got there by accident, not by policy. Which branch did your team actually choose, and where is that written down? If nobody can answer, the first installer made the choice.
Do not claim that a narrower branch is automatically safer. A CU can remove a serious reliability issue you have not yet recognized. A GDR can still require downtime and application testing. The real choice weighs exposure, known defects, change frequency, and the team’s ability to validate updates.
Write the target build into the patch plan. “Latest security patch” can mean different packages for different baselines. The exact build and KB entry remove that ambiguity.
Understand a Branch Change
Moving from a GDR baseline to a CU baseline is a real change in fix content. Test the selected CU on a representative instance. Read its known issues. Check the official servicing table for the path from your current build. Do not infer the route from numeric order alone.
After moving onto the cumulative update path, future security updates can have a GDR build based on that path. Keep the branch in the inventory. A simple report that labels every GDR as “base only” will be wrong. The full build and release entry settle the question.
Returning to an earlier branch is not a casual toggle. It can involve uninstalling an update and restoring a compatible prior state. Plan it as a recovery procedure, with backups and test evidence. Do not promise a one command reversal during a production incident.
Check the Package Scope
A SQL Server update can touch shared components as well as a Database Engine instance. On a host with several instances, confirm which targets the package will patch. Document the installed features and their results in the setup summary. A branch report based only on one engine query does not describe every component.
Review the operating system and application support matrix too. A driver or vendor tool can have a certified build range. Ask the owner before changing a critical workload. The patch decision should include the complete service path.
Keep installation media and current backups available. A successful patch should be verified by the running ProductVersion, setup logs, application checks, and backups after maintenance. A branch label is only a summary of that evidence.
Report Branch Drift Clearly
Group instances by major version, approved target, and servicing branch. Flag a server whose exact build is not in the approved set. Also flag a server that stopped reporting. An old inventory row should not be marked compliant because it once matched.
Two servers in the same availability group on different branches deserve their own line in the report, because it changes which packages each one can take next.
For each exception, show owner, current build, target build, test status, and next maintenance window. A server can have a valid temporary exception for a vendor certification gap. Give it an expiry date. Hiding exceptions weakens the report.
I prefer a report that says “review branch” to one that sorts version strings and announces a false winner. SQL Server servicing history is a lookup problem. Use the official mapping and make the next action clear.
Revisit the GDR or CU Policy
As a release ages, CU cadence changes and the available servicing options change. Review the branch policy when a major version moves toward the end of support, when a security bulletin arrives, or when a CU fixes a problem you have. A policy written once and forgotten becomes drift.
Keep the decision small enough for operations to use. State which branch each application follows, who approves a change, how it is tested, and how the final build is verified. This lets the patch team act without guessing.
The goal is consistent, supportable instances. The branch name helps organize the work, but the exact running build and workload evidence decide whether you are actually current.
Related reading on this blog: What a Cumulative Update Actually Contains and How to Check Your SQL Server Version, Edition and Patch Level.
GDR or CU is not a badge of caution, it is a documented servicing choice for a specific workload.
Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.
