Today we are re-releasing the November 2024 SUs for Exchange Server. The original release of these SUs (released on 11/12/2024) introduced an issue with Exchange Server transport rules stopping after...
Updated Jan 28, 2025
Version 11.0
Blog Post
ugh planing to install the v2 update tomorrow; however, seeing that you and Sven_helloworld are having issues, I am thinking of postponing....
LukasSMSFT
Microsoft
MicrosoftWe've published a workaround for this issue: https://support.microsoft.com/en-us/topic/time-zone-exception-occurs-after-installing-exchange-server-november-2024-su-version-1-or-version-2-851b3005-6d39-49a9-a6b5-5b4bb42a606f
Hi LukasSMSFT Thanks for your quick reply. Nick8100 applied the workaround and he still has messages stuck in submission and poison queues.
I am afraid we will experience the same issues even after applying the workaround.
- LukasSMSFT
Applying the workaround will not automatically remove emails from Poison Queue but will prevent new emails with .ical or .ics attachments from ending up there. We heard from other customers that applying the workaround addresses the issue for them. If you see event 1026 being logged to the Application event log, with Application: MSExchangeDelivery.exe and Exception Info: Microsoft.Exchange.ExchangeSystem.InvalidTimeZoneException, this will be addressed by the workaround as mentioned in KB.
Hey all, I am on leave but saw the activity here. I pulled the v2 update before I left as to not leave our environment broken. There was nothing in the Poison queue prior to installing v2 and applying the workaround. It took about 2 days after applying before the queue issue appeared (same scenario as with v1) - may have just been timing to get a message that caused the issue?
For both incidents (v1 and v2), the message(s) in the Poison queue were Microsoft Purview Encrypted Message notifications with an .rpmsg attachment (not ical or ics) and were not throwing any errors about the Time Zone in the event viewer. The Transport service was continually crashing and restarting. Pulling the patch immediately resolved the issue.
This happened on both our 2016 and 2019 servers with v2 and workaround applied.
I'm fairly nervous now to re-apply this but when I return I will have to and open a ticket with MS Support as we need some sort of quick turnaround for resolution. The crashing of the Transport service was causing the queues to back up into the thousands.
