Checking the Update History of an Instance

The patch ticket is missing, but the server still leaves clues. Its update history can be rebuilt from Setup logs, startup logs, and the running build.

Start With the Running Build

Connect to the exact instance and capture its full ProductVersion, update label, edition, and machine name. The version tells you the current state, not every step taken to reach it. Map it to Microsoft’s build history before naming the CU or GDR branch.

I ask for the actual connection target first. A listener can move between replicas. A Windows host can carry several named instances. The current build from one connection does not prove the history of its neighbor. Save the capture time and the identity returned by SQL Server.

What if the build is newer than your last spreadsheet row? That tells you a change happened, not when it happened or which installer ran. Keep the question open until the logs provide a date.

SELECT
    @@SERVERNAME AS RegisteredName,
    SERVERPROPERTY('MachineName') AS MachineName,
    SERVERPROPERTY('ProductVersion') AS ProductVersion,
    SERVERPROPERTY('ProductUpdateLevel') AS UpdateLevel,
    SERVERPROPERTY('ProductBuildType') AS BuildType;

Read Setup Bootstrap Logs

SQL Server Setup writes a Summary.txt and dated run folders under Setup Bootstrap Log. Look for the folder matching each installation or patch attempt. The summary names the operation, package, features, and result. Detail.txt and feature logs explain failures. Preserve the folders before cleanup or a rebuild removes them.

Do not turn every Setup folder into a successful update. An attempt can fail, be canceled, or patch only some components. Read the result for the intended instance and shared features. Record the package, start time, outcome, and reported build. If a repair ran later, include that too.

I put each finding into a timeline with the source file name. It is slower than reading one invented history table, but it is honest. A green setup line for the Database Engine and a red line for another component need separate entries.

Search the SQL Server Error Log

Each Database Engine start writes version and recovery information to the SQL Server error log. Compare startup entries around the Setup run times. A restart after a patch can show the engine build that actually ran. Archived logs extend the timeline only as far as retention permits.

Use sp_readerrorlog for an accessible view, or inspect the files through your approved log process. Search for the version banner and nearby startup errors. The current error log is only one slice. Check archived logs if they remain. Record the log date, instance, and full version.

A patch can install files yet fail at service startup. The error log and Setup summary then tell different parts of the story. Which one answers “what was running”? The startup line. Setup answers “what did the installer attempt?”

EXEC sys.sp_readerrorlog 0, 1, N'Microsoft SQL Server';

Include Windows Evidence Carefully

Windows installed update history can identify packages applied to the host. It is supporting evidence, not a substitute for a direct SQL Server version check. A host can run several instances. Shared components and instance features can have different outcomes.

Check the operating system event log around Setup and restart times if the SQL logs are incomplete. Look for service stop, start, and installer events. Keep the time zone in mind when combining entries. A timestamp copied without its zone can put events in the wrong order.

I avoid a timeline that claims more precision than its sources. If archived SQL logs were removed, mark that interval unknown. An absence of evidence from a cleaned folder is not evidence that no patch ran.

Build the First Trustworthy Update History Row

Once you have the current build and enough log evidence, make a baseline record. It should include instance key, full ProductVersion, current branch, observation time, and source references. Add prior patch events only where logs support them. Mark inferred dates as inferred, not confirmed.

From this point forward, collect the build on a schedule. A daily or weekly snapshot makes the next investigation much easier. Store the capture time with each row and alert on missing captures. A server that stops reporting can be down, moved, or simply forgotten by the collector.

A future patch ticket should attach before and after queries and the Setup summary. This takes little effort during a planned window and saves hours when a support case asks for history.

Explain Gaps and Conflicts in the Update History

Two sources can disagree. Setup can report a successful package, while SERVERPROPERTY still shows an older build. Check whether the service restarted, whether you connected to the right instance, and whether a feature failed. Do not force the evidence into a neat story before resolving it.

A CU label can remain the same after a later security update on that baseline. Compare the full version and build type. A host patch record can also include an update to a different SQL Server instance. Identity belongs beside every log entry.

When the evidence cannot establish a date, say so. Give a bounded interval if you have a snapshot before and after. That is more useful than assigning the date of the oldest surviving log.

Keep the Update History Timeline Alive

Put the reconstructed timeline in a place the operations team maintains. Add package identity, change ticket, affected instance, start and finish times, setup result, observed running build, and any restart. Keep the raw logs under your retention policy.

Review a sample after the next patch. Does the captured build match the official package note? Does the Setup summary name every intended feature? Did the error log show a healthy restart? If the answer is unclear, improve the collection step while the window is fresh.

A server does not remember its maintenance history for you. Give it a dated record now, and the next incident starts with facts.

Related reading on this blog: How Old Version of SQL Server Running on Server? Interview Question of the Week #183 and Patch Your SQL Server: SQL in Sixty Seconds #100.

Update history is not one version string, it is a timeline built from independent evidence.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.