Microsoft Patch Tuesday - August 2024

[Esben_D]

The August 2024 edition of Patch Tuesday brings us 86 new fixes, with 7 rated as critical and 6 exploited. Additionally, I've also used the the new format of report as was discussed on the forum here: https://community.lansweeper.com/t5/reports-analytics/patch-tuesday-improvement/m-p/75608

You can find all the info and report in the August blog post.

[vinnes]

The on-prem report fails with the following error:

'Try_Convert' is not a recognized built-in function name. Incorrect syntax near the keyword 'As'. Incorrect syntax near the keyword 'As'. Incorrect syntax near the keyword 'As'. Incorrect syntax near the keyword 'As'.

[Esben_D]

@vinnes I found online that TRY_CONVERT function is supported by SQL Server 2012 and higher. If you have an older SQL Version, that will be the issue.

A way to resolve it is to replace the TRY_CONVERT to just the regular CONVERT. The Try was added as an extra safety mechanism to avoid errors, but I didn't know that it was limited to newer versions.

What database version are you using?

[vinnes]

@Esben_D Microsoft SQL Server 2022 (RTM-CU14) 

[vinnes]

@Esben_D Just tried replacing the TRY_CONVERT with CONVERT, and that seems to work.

[Esben_D]

very strange, it literally lists on the Microsoft website that TRY_CONVERT is supported...

https://learn.microsoft.com/en-us/sql/t-sql/functions/try-convert-transact-sql?view=sql-server-ver16

I updated the report with an alternative to TRY_CONVERT

CASE
WHEN ISNUMERIC(tblAssets.BuildNumber) = 1 THEN CONVERT(bigint, tblAssets.BuildNumber)
ELSE NULL
END as Buildnumber

[vinnes]

@Esben_D Works perfectly now! Thanks!

[donohue17]

Changing Try_Convert to Conver let the report create. But when I scan servers that have been patched, they do not turn Green and still show they need patched. 

OS: Server 2016 Datacenter

SQL: SQL Server 2022 Express Edition (64-bit) CU14

LANSweeper version: 11.4.0.3

[Esben_D]

@donohue17 You can see in the query which minimum build number is required for a specific OS version. You can compare that to the build number the report is displaying. It might be possible that a reboot of the device is needed.

    WHEN tsysOS.OScode LIKE '10.0.10240%' And SubQuery2.Buildnumber >= 20751 Then 'Up to date'
    WHEN (tsysOS.OScode LIKE '10.0.14393%' OR tsysOS.OSname = 'Win 2016') And SubQuery2.Buildnumber >= 7259 Then 'Up to date'
    WHEN tsysOS.OScode LIKE '10.0.17763' AND tblOperatingsystem.Caption LIKE '%LTSC%' And SubQuery2.Buildnumber >= 6189 Then 'Up to date'
WHEN tsysOS.OSname = 'Win 2019' And SubQuery2.Buildnumber >= 6189 Then 'Up to date'
    WHEN tsysOS.OScode LIKE '10.0.19044%' And SubQuery2.Buildnumber >= 4780 Then 'Up to date'
    WHEN tsysOS.OScode LIKE '10.0.19045%' And SubQuery2.Buildnumber >= 4780 Then 'Up to date'
WHEN tsysOS.OSname = 'Win 2022' And SubQuery2.Buildnumber >= 2655 Then 'Up to date'
    WHEN tsysOS.OScode LIKE '10.0.22000%' And SubQuery2.Buildnumber >= 3147 Then 'Up to date'
    WHEN (tsysOS.OScode LIKE '10.0.22621%' OR tsysOS.OScode LIKE '10.0.22631%') And SubQuery2.Buildnumber >= 4037 Then 'Up to date'
    WHEN tsysOS.OScode LIKE '10.0.25398%' And SubQuery2.Buildnumber >= 1085 Then 'Up to date'

[donohue17]

It appears only Server 2019 is showing wrong on the report for colors. Text shows patched but colors are red.

 

[Ode2Joy]

I'm loving that this month's report seems to indicate devices that may have been patched but still haven't been rebooted as 'out of date'.  That is fantastic!  However, I'm missing the column that used to tell exactly which KB was needed to get the system in question up to date.  Is there a way to get that back?

[Esben_D]

@donohue17 Thanks for showing me. I have updated the report to fix it!

If you refresh the report page and copy/paste it again, it should be fixed. There were some wildcards I forgot to remove.

[Esben_D]

@Ode2Joy There is a way of getting it back, but its more effort for me every month 😔

Do you use that info frequently to trigger the specific update?

The reason why I decided to leave this out is because the new report works with builds (where possible) rather than individual patches. This is much more future proof since listing a specific patch is only correct as long as that is the latest patch.

[Ode2Joy]

@Esben_D, I definitely do not use that enough to warrant additional work, and actually like this format much better! Is there a way to easily identify which devices have the patches and just need a reboot vs. those with no patch at all? 

[Esben_D]

@Ode2Joy I actually put it live just now, you can refresh the page and try it out: https://www.lansweeper.com/resources/report/patch-tuesday/microsoft-august-2024-patch-tuesday-audit/

The idea is to take the highest installed date (time is not provided) and use that to try and provide information on potential reboots.

The basic logic will be:

• if device's last power on event was on the same day as the patch installed = Reboot might be required
• if device's last power on event was on an older date as the patch installed = Reboot required
• if device's last power on event was on an newer date as the patch installed =  Blank (No action required)
• if the build number already indicates the asset is up-to-date = Blank (No action required)

I want to avoid any kind of static list of patches (as those too easily go out-of-date), but the highest installed patch date should also give you an indication whether a recent patch is installed or not.

[JanC]

@Esben_D I just tried the newest script from the link : https://www.lansweeper.com/resources/report/patch-tuesday/microsoft-august-2024-patch-tuesday-audit/

on my On-prem installation  - but i cant save and run the script - it has this error