We have addressed the issue causing messages to be stuck in transport queues of on-premises Exchange Server 2016 and Exchange Server 2019. The problem relates to a date check failure with the change ...
Updated Jan 11, 2022
Version 36.0
Blog Post
Download errors observed - notice the difference in time stamps of engine updates and in UpdateVersions post-update (on my first run) what is on the system and what is available online:
<...>
--------
Attempted to divide by zero.
At C:\Reset-ScanEngineVersion.ps1:102 char:25
+ ... $percentComplete = ($transfer.BytesTransferred * 100 / $t ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [], RuntimeException
+ FullyQualifiedErrorId : RuntimeException
[PS] C:\>
[PS] C:\>Get-EngineUpdateInformation
Engine : Microsoft
LastChecked : 01/03/2022 01:01:14 PM -05:00
LastUpdated : 01/01/2022 03:03:04 AM -05:00
EngineVersion : 1.1.18800.4
SignatureVersion : 1.355.1224.0
SignatureDateTime : 12/31/2021 08:03:32 PM -05:00
UpdateVersion : 2201010004
UpdateStatus : UpdateAttemptNoUpdate
[PS] C:\>
Rerunning the script:
<...>
[D] Do not run [R] Run once [S] Suspend [?] Help (default is "D"): R
<server-name> UpdateVersion: 2112330003
<server-name> This server is not impacted. Add -Force to proceed anyway.
Oh yes, it is.
[PS] C:\>.\Reset-ScanEngineVersion.ps1 -force
<server-name> Downloading scan engines
0 / 0
[oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo]
I can see where the Divide by zero error is coming from when download was timing out.
<server-name> Downloading scan engines
0 / 179030563
[ ]
And then download restarted at around 11,4xx,xxx out of 179,xxx,xxx engine updates on the counter.
Check your UpdateVersion after update run for LastChecked and LastUpdated to match, and your UpdateVersion to be at least 2112330003.