image

Microsoft komt met oplossing voor datumprobleem Exchange Server

maandag 3 januari 2022, 08:47 door Redactie, 15 reacties

Microsoft heeft een oplossing beschikbaar gemaakt voor een datumprobleem in Exchange Server waardoor er geen e-mail kan worden afgeleverd. Het probleem wordt veroorzaakt door een fout in de datumcontrole die sinds de wisseling naar het nieuwe jaar ervoor zorgt dat de malware-engine van Exchange crasht waardoor er e-mail in de transport queues blijft staan. De variabele waarin Exchange de datum wil opslaan is te klein voor de nieuwe datum, wat voor de crash zorgt.

Om het probleem te verhelpen heeft Microsoft een script beschikbaar gesteld. Beheerders moeten dit script zelf uitvoeren. "Het implementeren van deze oplossing vereist actie van de klant, en het zal enige tijd kosten om de noodzakelijke aanpassingen te maken, geüpdatete bestanden te downloaden en de transport queues op te schonen", aldus Microsoft.

Het is wel mogelijk om de verschillende acties met het scanengine-resetscript te automatiseren of die handmatig uit te voeren. "Of je de stappen nu automatisch of handmatig uitvoert, ze moeten op elke on-premise Exchange 2016- en Exchange 2019-server in je organisatie worden uitgevoerd", stelt Microsoft. Het is wel mogelijk om het geautomatiseerde script op meerdere servers tegelijkertijd uit te voeren.

Reacties (15)
03-01-2022, 09:29 door Anoniem
maar mooi spul hoor dat exchange....
03-01-2022, 09:41 door Anoniem
Helaas blijft het niet bij MS,
We merken in productie dat andere applicaties (meeste 32 bit versies) ook problemen hebben.

Hoor ook om me heen dat het daar niet goed gaat met applicaties.

- FluFFy
03-01-2022, 09:57 door Anoniem
De variabele waarin Exchange de datum wil opslaan is te klein voor de nieuwe datum, wat voor de crash zorgt.
Ongelooflijk. In de 70/80-er jaren waren 'bytes' nog duur.
Hoe oud is die software eigenlijk?
03-01-2022, 11:44 door Anoniem
De "oplossing" is dat Microsoft extra data heeft gecreëerd in december. 1 januari 20211232###### en 2 januari 20211233######. Het zal vast opgelost worden in de volgende CU die is uitgesteld (en in december had moeten komen).

Met andere woorden, de oplossing is eigenlijk een temporary solution en werkt alleen, omdat kennelijk invalid dates toch valid zijn. Nieuwe entry voor mogelijke maliscious entries? Even om in je achterhoofd te houden dit. Er bestaat namelijk geen 20211233, 20211234, etc etc.

Wat me echt opvalt in de industry, en dat is echt breder dan alleen dit, is de hoeveelheid bugs, fixes, halve fixes, of andere problemen bij providers van datalijnen er momenteel zijn. Lijkt echt alsof de kwaliteit onder druk staat. Mogelijk gevolg van het remote werken, waarbij het "koffie apparaat momentje" er niet meer is? Oftewel het ohja momentje?
03-01-2022, 12:50 door Anoniem
Wat me echt opvalt in de industry, en dat is echt breder dan alleen dit, is de hoeveelheid bugs, fixes, halve fixes, of andere problemen bij providers van datalijnen er momenteel zijn. Lijkt echt alsof de kwaliteit onder druk staat. Mogelijk gevolg van het remote werken, waarbij het "koffie apparaat momentje" er niet meer is? Oftewel het ohja momentje?

ik denk dat je de oorzaak gaat vinden in perverse prikkels waar bedrijven mee te maken hebben die nu in corona tijd (crisis) uitvergroot worden omdat ze niet meer zo eenvoudig 'gemaskeerd' kunnen worden. net als houtrot, zodra je het ziet...
03-01-2022, 12:52 door Anoniem
Door Anoniem:
De variabele waarin Exchange de datum wil opslaan is te klein voor de nieuwe datum, wat voor de crash zorgt.
Ongelooflijk. In de 70/80-er jaren waren 'bytes' nog duur.
Hoe oud is die software eigenlijk?
Pas 17 jaar. Dan verwacht je dat de meeste bugs er toch wel uit zijn he. Niet genoeg eye balls.
03-01-2022, 13:35 door Briolet - Bijgewerkt: 03-01-2022, 13:39
De variabele waarin Exchange de datum wil opslaan is te klein voor de nieuwe datum, wat voor de crash zorgt.

Ik kan me de commotie nog herinneren van 22 jaar geleden, toen veel oudere software ook aangepast moest worden omdat het datumveld te klein was.*

Rond de eeuwwisseling was het geheugengebruik van een datumveld zo goedkoop dat het onbegrijpelijk is dat men sindsdien niet 100 jaar vooruit dacht bij het schrijven van code.

*) Een collega programmeur moest in die tijd een financieel programma controleren op deze millennium bug. Hij mocht echter niet gelijktijdig de BTW bug fixen. Het BTW percentage stond nml als een fixed getal in de code en het was toen al bekend dat de btw in 2001 weer aangepast zou gaan worden. Het percentage was zelfs al bekend. Op die manier wist het bedrijf zeker dat hun klanten het daar daarop weer een update moesten kopen.
03-01-2022, 14:36 door Bitje-scheef
Ik moet me toch enigszins inhouden, wat knullig.
03-01-2022, 15:21 door spatieman
man,man,man.
echt.
Ze hadden 22 jaar de tijd om voor een oplossing te komen.
03-01-2022, 16:46 door Anoniem
Door Briolet:
*) Een collega programmeur moest in die tijd een financieel programma controleren op deze millennium bug. Hij mocht echter niet gelijktijdig de BTW bug fixen. Het BTW percentage stond nml als een fixed getal in de code en het was toen al bekend dat de btw in 2001 weer aangepast zou gaan worden. Het percentage was zelfs al bekend. Op die manier wist het bedrijf zeker dat hun klanten het daar daarop weer een update moesten kopen.
Ik heb ooit nog wel meegewerkt aan een pakket waarin BTW wel configureerbaar was maar het percentage was 2 cijfers
dus altijd een integer. Op een gegeven moment kwam er een BTW percentage met ,5 maar toen was ik allang niet meer
bij dat pakket betrokken, dat heeft vast ook paniek veroorzaakt.
03-01-2022, 19:13 door Anoniem
Door Anoniem: Met andere woorden, de oplossing is eigenlijk een temporary solution en werkt alleen, omdat kennelijk invalid dates toch valid zijn. Nieuwe entry voor mogelijke maliscious entries? Even om in je achterhoofd te houden dit. Er bestaat namelijk geen 20211233, 20211234, etc etc.
Nou, als je lang genoeg wacht, misschien wel.
Of het wordt de standaard in Windows 13 :)
03-01-2022, 19:17 door Anoniem
Door spatieman: Ze hadden 22 jaar de tijd om voor een oplossing te komen.
Ja echt, tijd zat. Waarom zou je er nu dan ook iets aan doen, als je het ook aan je opvolger kan overlaten.
03-01-2022, 21:21 door Anoniem
Mogen we iets denken? Powershell? (en dan denk ik iets in de trend van ons-kent-ons de cartoonreeks van demorgen, altijd gemeen(d)!).
04-01-2022, 11:07 door Anoniem
Kan hier eigenlijk maar 1 ding over zeggen.

man man man man.
04-01-2022, 13:58 door Anoniem
Door Briolet:
De variabele waarin Exchange de datum wil opslaan is te klein voor de nieuwe datum, wat voor de crash zorgt.

Ik kan me de commotie nog herinneren van 22 jaar geleden, toen veel oudere software ook aangepast moest worden omdat het datumveld te klein was.*

Rond de eeuwwisseling was het geheugengebruik van een datumveld zo goedkoop dat het onbegrijpelijk is dat men sindsdien niet 100 jaar vooruit dacht bij het schrijven van code.

Het geheugengebruik is al heel lang niet duur meer.
Wat wel - en nog steeds - 'duur' is , is werken met datatypes die groter zijn dan de natuurlijke word-size van de processor.
Het kan , en soms moet het , maar het komt zichtbaar en onzichtbaar met veel extra dingen.

In heel kritische secties van code is het nog steeds extreem pijnlijk als een enkele variable groter is dan een cache line / cq de registerbreedte van de processor . ( updates zijn opeens niet meer atomic )

En het heeft best een tijd geduurd voordat een 64-bit integer een 'normaal' datatype werd - ook op 32 bit systemen.
Wie er genoeg bij was heeft het lange proces kunnen zien waarin 'large file support' (files >2 of 4 G) aan Linux werd toegevoegd . Toen de disk-sizes groot werden, maar de CPUs nog veel 32 bit waren.
https://en.wikipedia.org/wiki/Large-file_support

(hint : 2G is de grootste waarde die een signed 32 bit integer kan aangeven, en 4G de grootste waarde van een unsigned 32 bit integer) .

Dat is ook de tijd waarin dit "serie nummer geformat als datum en verwerkt als signed 32 bit integer" geschreven werd.

Een _unsigned_ integer was waarschijnlijk een betere keuze geweest. Maar het is vrij gebruikelijk om een negatieve waarde (-1) te gebruiken als fout-indicactie . Goede kans dat als de "datum" conversie misgaat de functie zo'n waarde returned , en dat het daarom een signed (32 bit) integer is.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.