Mastering Windows Updates & Microsoft Updates – Part 2
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 we will troubleshoot Azure virtual machines they will either stuck during updates or just looking like stuck and how to determine and solve it.
We will also take a look 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
- Azure Virtual Machine is stuck at Getting Windows ready – Don't turn off your computer
- What is the Extended Security Update (ESU) program?
- Troubleshooting Extended Security Update (ESU)
- Determine which version and edition of SQL Server Database Engine is running
- Method 1: Connect to the server by using SQL Server Management Studio
- Method 2: Look at the first few lines of the Errorlog file
- Method 3: Look at the output after running the query "SELECT @@VERSION"
- Method 4: Use the SERVERPROPERTY function
- By using the SQLCMD command-line tool is installed (Access Permissions needed)
- Determine without SQL Management or in general without Access Permissions
- Links
Azure Virtual Machine is stuck at Getting Windows ready – Don’t turn off your computer
If this is an Azure VM that’s stuck on “Getting Windows ready. Don’t turn off your computer” and we still have serial console access (CMD or PowerShell), then we have more options than with a bare-metal server to troubleshoot.

To use the serial console in Azure to finally accessing a CMD or PowerShell session, you can read my following post.
To use the serial console in GCP to finally accessing a CMD or PowerShell session, you can read my following post.
After successfully connected to the CMD and opened from there a new PowerShell session, we can first check if the setup is still running or the machine is stucking by running.
If any of those are alive and consuming CPU, Windows is still working on updates. In that case → better to wait longer.
tiworker.exe → Windows Modules Installer Worker, handles update installation.
TrustedInstaller.exe → core service that installs/removes Windows updates.If those are still running, it usually means Windows is still processing the update, even if the “Getting Windows ready” screen looks stuck.
PS> Get-Process tiworker, trustedinstaller

If CPU is >0 or memory/disk usage is non-zero, it’s actively working → wait.
If CPU is 0 for many minutes and no disk activity (shown below how to measure), it might be stuck → then we intervene.
PS> Get-Process tiworker, trustedinstaller | Select-Object CPU, Id, ProcessName

Shows total disk bytes/sec in real time.
Higher numbers indicate active disk I/O.
Press Ctrl+C to stop.
PS> Get-Counter '\PhysicalDisk(_Total)\Disk Bytes/sec' -Continuous

In my case after roughly 1 hour I could finally logon again.

In case our virtual machine really seems to stuck, we can stop update services by running.
This can sometimes leave updates in a “pending” state, so use only if it’s stuck >1–2 hours with zero activity.
> net stop wuauserv > net stop bits > Stop-Process -Name tiworker -Force > Stop-Process -Name trustedinstaller -Force
We can also check for pending reboots like shown in Part 1 and by checking if the following file exists.
The pending.xml file in C:\Windows\WinSxS\ is a temporary file that contains information about pending Windows updates or operations.
It is created and used by the Windows servicing stack to manage updates, but if it becomes corrupted or stuck, it can cause update errors. To resolve issues, you may need to use an elevated Command Prompt to rename or delete pending.xml to clear stuck update operations, often in conjunction with other steps like clearing the Software Distribution folder.
> dir C:\Windows\WinSxS\pending.xml # if it exists > rename C:\Windows\WinSxS\pending.xml pending.old

Once you’ve stopped the stuck processes or cleared pending files trigger a reboot.
On reboot, Windows may continue applying updates or undo changes.
After it boots, check Event Viewer → Setup for any failed updates.
> shutdown /r /t 0
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.
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-deployLifecycle FAQ – Extended Security Updates
https://learn.microsoft.com/en-us/lifecycle/faq/extended-security-updates?culture=en-us&country=usTroubleshoot delivery of Extended Security Updates for Windows Server 2012
https://learn.microsoft.com/en-us/azure/azure-arc/servers/troubleshoot-extended-security-updates