In Part 1 we will see how to master Windows Updates successfully, why they sometimes fail, and what we can do in case something went wrong.

Further we will also see there the difference between Windows and Microsoft Updates and their different settings we need to understand.

Now in this part will see what exactly the Extended Security Update (ESU) program for Windows operating systems is and how to determine the current SQL server versions installed on Windows.

For the Extended Security Update (ESU) will also see some troubleshooting in case the system couldn’t successfully validate if its eligible to receive ESUs



What is the Extended Security Update (ESU) program?

The Extended Security Update (ESU) program is a last resort option for customers who need to run certain legacy Microsoft products past the end of support.

They are not intended as a long-term solution, but rather as a temporary bridge to stay secure while one migrates to a newer, supported platform.

It includes Critical* and/or Important* security updates up to three years after the product’s End of Extended Support date.


Extended Security Updates will be distributed if and when available. ESUs do not include new features, customer-requested non-security updates, or design change requests.

The ESU program does not extend the product lifecycle or extend complete technical support for the product beyond its lifecycle. For more information, please refer to Support questions for ESUs.

Source: https://learn.microsoft.com/en-us/lifecycle/faq/extended-security-updates

Troubleshooting Extended Security Update (ESU)

Azure Update Manager also supports Extended Security Updates (ESU) for Windows Server, particularly for versions like Windows Server 2012 and 2012 R2, which reached end of support in October 2023.

Azure-hosted VMs are automatically eligible for ESUs, no need for activation keys or manual enrollment and ESUs are free of charge.

If your servers are on-premises or in a hosted environment, you can enroll your Windows Server 2012 and 2012 R2 or SQL Server 2012 machines for Extended Security Updates via the Azure portal through Azure Arc. Once enrolled you’re billed monthly via your Azure subscription.

To learn more, see Extended Security Updates enabled by Azure Arc .

If you can’t connect using Azure Arc, use Extended Security Updates on non-Azure VMs, by using a Multiple Activation Key (MAK) and applying it to the relevant servers. This MAK key lets the Windows Update servers know that you can continue to receive security updates.

To learn more, see Access your Multiple Activation Key from the Microsoft 365 Admin Center . 

More about how to get ESUs you will find here https://learn.microsoft.com/en-us/windows-server/get-started/extended-security-updates-deploy.


We couldn’t complete the updates – Undoing changes – Don’t turn off your computer

For the following Azure-hosted Windows Server 2012 R2 virtual machine I was always running into the following error. Even after trying the usual workarounds as shown in Part 1 including  installing the latest SSU (Servicing Stack Update) .

We couldn’t complete the updates – Undoing changes – Don’t turn off your computer


Next I was trying to analyzing the CBS logs right after the rollback completes. The following command will find all error messages within the log file and writes them to a new file cbs_errors.txt placing on the users desktop for further analyzing.

findstr /i /c:"error" /c:"fail" /c:"0x800f" %windir%\Logs\CBS\CBS.log > %userprofile%\Desktop\cbs_errors.txt


More about the Component-Based Servicing (CBS) you will find here https://blog.matrixpost.net/mastering-windows-updates-microsoft-updates-part-1/#ssu

We can also just upload the C:\Windows\Logs\CBS\CBS.log file to ChatGPT or any other ChatBot, analyzing log files for errors is one of their master disciplines.

So seems that the W2K12 machine couldn’t check/prove its eligible for ESUs, actually as mentioned Azure-hosted VMs are automatically eligible for ESUs, no need for activation keys or manual enrollment and ESUs are free of charge.


Now at least I could determine it must have something to do with checking/proving its eligible for ESUs.

A good old classic web search for the above highlighted ESU: check failed E_FAIL error message logged within C:\Windows\Logs\CBS\CBS.log and revealed by ChatGPT finally leads me to the following Microsoft article.

Troubleshoot delivery of Extended Security Updates for Windows Server 2012
https://learn.microsoft.com/en-us/azure/azure-arc/servers/troubleshoot-extended-security-updates#option-2-manually-download-and-install-the-intermediate-ca-certificates


The listed Microsoft Azure RSA TLS Issuing CA 03, 04, 07 and 08 intermediate certificates in this article were all missing on my Windows Server 2012 R2 virtual machine in Azure, because of this the Microsoft’s ESU licensing service, which the client connects to via HTTPS/TLS, couldn’t trust the TLS certificate presented by this HTTPS service (Microsoft endpoints) and the connection and validation will fail.

Actually the machines automatically retrieve any missing intermediate CA certificates from Microsoft, in case you will filter outbound internet traffic and doesn’t allow access to http://www.microsoft.com/pkiops/certs and https://www.microsoft.com/pkiops/certs (both TCP 80 and 443), this will break automatic retrieve of these intermediate CAs.

Source: https://learn.microsoft.com/en-us/azure/azure-arc/servers/troubleshoot-extended-security-updates#option-1-allow-access-to-the-pki-url


To enable Extended Security Updates (ESU) for Windows Server 2012/2012 R2 or SQL Server 2012, your machines must be able to reach specific Microsoft ESU license server endpoints.

Under the following link all endpoints for Windows 10 will be listed.

  • https://go.microsoft.com/
  • https://login.live.com
  • https://activation.sls.microsoft.com/
  • http://crl.microsoft.com/
  • https://validation.sls.microsoft.com/
  • https://activation-v2.sls.microsoft.com/
  • https://validation-v2.sls.microsoft.com/
  • https://displaycatalog.mp.microsoft.com/
  • https://licensing.mp.microsoft.com/
  • https://purchase.mp.microsoft.com/
  • https://displaycatalog.md.mp.microsoft.com/
  • https://licensing.md.mp.microsoft.com/
  • https://purchase.md.mp.microsoft.com/

Determine which version and edition of SQL Server Database Engine is running


Method 1: Connect to the server by using SQL Server Management Studio

Connect to the server by using Object Explorer in SQL Server Management Studio (SSMS). Once connected, the version information will be displayed in parentheses, along with the username used to connect to the specific instance of SQL Server. For more information on how to connect to SQL Server using Object Explorer, see Connect to a SQL Server or Azure SQL Database.

Method 2: Look at the first few lines of the Errorlog file

Look at the first few lines of the Errorlog file for that instance. By default, the error log is located at Program Files\Microsoft SQL Server\MSSQL.n\MSSQL\LOG\ERRORLOG in ERRORLOG.n files. The entries may resemble the following one:

2024-09-05 16:56:22.35 Server      Microsoft SQL Server 2022 (RTM-CU14) (KB5038325) - 16.0.4135.4 (X64)  
Jul 10 2024 14:09:09  
Copyright (C) 2022 Microsoft Corporation 
Developer Edition (64-bit) on Windows 11 Enterprise 10.0 <X64> (Build 22631: ) (Hypervisor)


This entry provides information about the product, such as version, product level, 64-bit versus 32-bit, the edition of SQL Server, and the OS version on which SQL Server is running.

Method 3: Look at the output after running the query “SELECT @@VERSION”

Connect to the instance of SQL Server, and then run the following query:

SELECT @@VERSION

Here’s an example of the output of this query:

Microsoft SQL Server 2022 (RTM-CU14) (KB5038325) - 16.0.4135.4 (X64)   Jul 10 2024 14:09:09   Copyright (C) 2022 Microsoft Corporation  Developer Edition (64-bit) on Windows 11 Enterprise 10.0 <X64> (Build 22631: ) (Hypervisor)

From the output, you can determine the SQL Server product’s version, service pack level, cumulative update level, or security update level (if applicable).

Method 4: Use the SERVERPROPERTY function

Connect to the instance of SQL Server, and then run the following query in SSMS:

SELECT SERVERPROPERTY('productversion'), SERVERPROPERTY ('productlevel'), SERVERPROPERTY ('edition')

The following results are returned:

  • The product version (for example, 16.0.4135.4)
  • The product level (for example, RTM)
  • The edition (for example, Developer)


Source: http://learn.microsoft.com/en-us/troubleshoot/sql/releases/find-my-sql-version

By using the SQLCMD command-line tool is installed (Access Permissions needed)

sqlcmd -S localhost -E -Q "SELECT @@VERSION;"

Determine without SQL Management or in general without Access Permissions


Check the running engine binary (most reliable, no login needed)

# Get the sqlservr.exe file version for the default instance
$svc = Get-CimInstance Win32_Service -Filter "Name='MSSQLSERVER'"
$exe = ($svc.PathName -replace '^"(.+?)".*','$1')
(Get-Item $exe).VersionInfo | Select-Object ProductVersion, FileVersion, ProductName

Links

How to get Extended Security Updates (ESU) for Windows Server
https://learn.microsoft.com/en-us/windows-server/get-started/extended-security-updates-deploy

Lifecycle FAQ – Extended Security Updates
https://learn.microsoft.com/en-us/lifecycle/faq/extended-security-updates?culture=en-us&country=us