Sometimes you have to patch mission critical Windows servers and you want to see what’s going on in the background. The modern windows update dialogue provides little verbosity, especially when compared to apt or yum in the Linux world.
In the Windows 7 / Server 2012 days I used to just tail C:\Windows\WindowsUpdate.log and watch the update process, especially when troubleshooting, or when updates were hanging on install. Nowadays if you open that file, you get the following message:
Windows Update logs are now generated using ETW (Event Tracing for Windows).
Please run the Get-WindowsUpdateLog PowerShell command to convert ETW traces into a readable WindowsUpdate.log.
For more information, please visit https://go.microsoft.com/fwlink/?LinkId=518345
As we can see, Microsoft have ditched text based logging in favour of ETW based logging. The link provided takes you to an article on Windows Update log files which lists out the various log files and what they do. If you want a concise log that is the same as what you got in Server 2012, then you have to run Get-WindowsUpdateLog which will spit out that familiar log file. This is no good in my situation, as that generated log file would be for the point in time it was generated, not a dynamically updated log file being written to during updates.
Since I don’t care really about the log contents and I just want to see some verbosity in the update process while its happening, I went through the other logs listed and came across the CBS log. CBS stands for Component based servicing and it provides output on update installation…. great!
When reviewing the log, I identified that the lines containing the strings Appl and FOD make up the majority of the hundreds, or thousands of entries, when running a tail. I filtered these out and it seems that what’s left is mostly operational logging to do with the update engine. Since my goal is to watch Windows Update progress to ensure something is happening, I wrote a quick PowerShell one liner:
This command will get last 10 lines of the CBS log file, wait for new entries to be written, filter out Appl and FOD and write the results to the console.
If I want to get more details after patching is complete, I can always run Get-WindowsUpdateLog.
This may stop working at any point of course if Microsoft change something, but for now, it gives me peace knowing that the update stuck at 23% for 47 minutes is actually being installed and I’m not about to have a long night… or not too long anyway.
I was recently working on an issue where a monitoring system that runs on top of Server 2012 R2 was not able to establish a TLS handshake with web servers to check their availability. After some investigation and a ticket with Microsoft, it was determined that SCHANNEL on Server 2012 R2 does not support modern ciphers (a few posts on Stack Overflow confirms the same thing).
I find it crazy that Microsoft don’t support modern ciphers on server operating systems that are still in support (albeit extended support in this case). Surely as web servers start to upgrade their cipher suites, this is going to break stuff and everyone will be forced to upgrade to newer Server OS’s whether they are ready to or not.
The troubleshooting process with Microsoft involved the following steps:
Make sure that the TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 cipher exists in the following registry locations:
Lastly, to make sure that a TLS 1.2 connection was established, the following registry keys needed to be set to enforce TLS 1.2 and disable older SSL and TLS protocols.
Once these registry keys were set and after a reboot, we could do some testing. The quickest way to determine what was happening was to run a packet capture and use Internet Explorer to browse to the site that was attempting to handshake using the TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 cipher. Internet Explorer uses SCHANNEL for establishing TLS connections, so this is an easier test than mucking about with your app that also uses SCHANNEL. For the capture, I wrote a quick PowerShell script to use the built in netsh tool to capture packets and convert them to .pcapng for easy analysis using Wireshark.
# NetworkCapture.ps1
function startCapture {
param ()
netsh trace start capture=yes report=disabled
}
function stopCapture {
param ()
netsh trace stop
}
function convertCapture {
param ()
# Setup function variables
$ETLToolZipPath = "$env:USERPROFILE\Downloads\etl2pcapng.zip"
$CapturePath = "$env:LOCALAPPDATA\Temp\NetTraces\NetTrace.etl"
$PCAPNGPath = "$env:LOCALAPPDATA\Temp\NetTraces\$(Get-Date -Format dd-MM-yyy-hhmm)_NetTrace.pcapng"
$ETLToolPath = "$env:USERPROFILE\Downloads\etl2pcapng\x64\"
if ($ETLToolPath) {
Write-Host "Tool already exists, skipping..."
}
else {
# Get Windows ETL to PCAPNG tool
Invoke-WebRequest -Uri https://github.com/microsoft/etl2pcapng/releases/download/v1.4.0/etl2pcapng.zip -OutFile $ETLToolZipPath -UseBasicParsing
# Unzip the archive
Expand-Archive -Path $ETLToolZipPath -DestinationPath $env:USERPROFILE\Downloads\ -Force
}
# Run conversion
Set-Location -Path $ETLToolPath
.\etl2pcapng.exe $CapturePath $PCAPNGPath
Write-Output -InputObject "Capture has been converted and can be found here: $PCAPNGPath"
}
Here is the result from running the three functions listed in the above script. In between the startCapture and stopCapture functions, using Internet Explorer, I browsed to the site using the TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 cipher.
PS C:\> startCapture
Trace configuration:
-------------------------------------------------------------------
Status: Running
Trace File: C:\Users\lab\AppData\Local\Temp\NetTraces\NetTrace.etl
Append: Off
Circular: On
Max Size: 250 MB
Report: Disabled
PS C:\> stopCapture
Merging traces ... done
File location = C:\Users\lab\AppData\Local\Temp\NetTraces\NetTrace.etl
Tracing session was successfully stopped.
PS C:\> convertCapture
Tool already exists, skipping...
IF: medium=eth ID=0 IfIndex=11
IF: medium=eth ID=1 IfIndex=14
Converted 208 frames
Capture has been converted and can be found here: C:\Users\lab\AppData\Local\Temp\NetTraces\01-02-2021-0856_NetTrace.pcapng
The results of the trace confirmed that the TLS 1.2 hello was not successfully negotiated:
From here we see the client reaches out with the TLSv1.2 hello, but further down the server returns with “Handshake Failure”.
In the Windows system event log, we also see the following SCHANNEL error:
At this point I did some additional testing using newer operating systems. I already knew that the sites in question worked using Windows 10 but I wanted to confirm with Server 2016 and Sever 2019. As expected, SCHANNEL supports the TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 cipher in newer versions of Windows and Internet Explorer is able to connect. The odd thing with Internet Explorer is that it throws the following error on Server 2012 R2, which is a bit misleading as RC4 is not in use or enabled:
This page can’t be displayed
Turn on TLS 1.0, TLS 1.1, and TLS 1.2 in Advanced settings and try connecting to https://site.example.com again. If this error persists, it is possible that this site uses an unsupported protocol or cipher suite such as RC4 (link for the details), which is not considered secure. Please contact your site administrator.
Another thing that proves the issue is with SCHANNEL is that Chromium on Server 2012 R2 works and you can access TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 negotiated sites fine. This is because Chromium does not use SCHANNEL for establishing TLS.
Ultimately, after collecting some more logs and a bit of back and forward on email, Microsoft came back stating that TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 is not supported on Windows Server 2012 R2 and that newer ciphers can be considered a windows ‘feature’ that has been introduced on newer operating systems only. They also provided this article as a reference.
If you come across this issue and your app uses SCHANNEL to establish TLS connections, you may be in for an OS upgrade.
Jesse's SysAdmin Blog 
You must be logged in to post a comment.