Microsoft Exchange stops passing mail due to bug on 1/1/22

Microsoft Windows

Ha valakit érint, itt talál megoldást: https://old.reddit.com/r/sysadmin/comments/rt91z6/exchange_2019_antimalware_bad_update/

A hiba valószínű oka: Can't convert "2201010002" to long (mivel ugye windows-on long max == 2,147,483,647)

1427 megtekintés

Mi lesz a fix, konvertálják unsigned long-ra? Az még 21 év, akkor már úgyse lesz támogatott.

A hozzászóláshoz be kell jelentkezni

Kinek van pénze Exchange 2019-re? ? Office 365 meg még mindig 2016, ha jól tudom.

trey @ gépház

A hozzászóláshoz be kell jelentkezni

egyetemeknek :) mivel nekik kb ingyen van...

A hozzászóláshoz be kell jelentkezni

Nekem is "ingyen" lenne MS partnerként, de a HW infra alá nem lenne két forint. Olcsóbb az O365.

Ha TCO-t számolunk, az nem csak a szoftverlicenc árából áll.

trey @ gépház

A hozzászóláshoz be kell jelentkezni

Nekem tavaly 2019-et tett fel az o365.eduid.hu-ról, de kollégámnak az új laposra 2021-et (vagy 22?) vagymit töltött le ugyanonnan. (SZTE, Szeged)

<-------
You can't grep on dead trees.

A hozzászóláshoz be kell jelentkezni

Szerintem te az outlookrol beszelsz.

A hozzászóláshoz be kell jelentkezni

Szerintem is.

trey @ gépház

A hozzászóláshoz be kell jelentkezni

Yup, lehet. "Office" - erről nekem a desktop jutott eszembe, sorry :)

<-------
You can't grep on dead trees.

A hozzászóláshoz be kell jelentkezni

Exchange 2016 is produkálja ... :(

A hozzászóláshoz be kell jelentkezni

Államigazgatás, ott kb mindegy mennyibe kerül, csak on-premise legyen.

A hozzászóláshoz be kell jelentkezni

mi ez, Y2k22 bug?

A hozzászóláshoz be kell jelentkezni

Komolyan így tárol valaki dátumot? Semmi logikus haszna nincs

A hozzászóláshoz be kell jelentkezni

Láttam már ilyet máshol is. Ugyanúgy lehet sorbarendezni, mint egy epoch timestampet. Emberi szemmel könnyebben olvasható. Komolyabb műveletek nélkül lehet évet, hónapot, napot kinyerni belőle.

A hozzászóláshoz be kell jelentkezni

Ez egy verzió szám, gondolom azért került bele a dátum, hogy ránézésre meg lehessen állapítani, mikor adták ki. Az Exchange valószínűleg elfogadna bármilyen számot, csak a 2718281828 vagy a 3141592653 verziószámból ez nem állapítható meg.

A hozzászóláshoz be kell jelentkezni

DNS zónafájlokban a SOA rekord verziószámát is ehhez hasonlóan (YYYYMMDDnn) szokás ábrázolni, lásd RFC1912 (igaz, ott csak a 4294-es évben fog túlcsordulni)

A hozzászóláshoz be kell jelentkezni

Szokas, de nem kotelezo. Siman inkrementalhatod is es kesz.

A hozzászóláshoz be kell jelentkezni

Node az csak azért dátum, mert így szokás. Amúgy lehetne akár 1 is az első. :)

A hozzászóláshoz be kell jelentkezni

Az ábrázolással nincs baj, csak azzal hogy ezt utána mint szám beleteszi egy long-ba. Ez DNS esetén pláne gázos lenne, mert az sokfajta rendszeren fut, és nem kötelező, hogy mindegyik ugyanakkora méretben tárolja a long-ot

A hozzászóláshoz be kell jelentkezni

Off: egy LPARAM/WPARAM tipusú változó kellett volna ide, az az intptr_t/uintptr_t Windows-os megfelelője.

https://devblogs.microsoft.com/oldnewthing/20031125-00/?p=41713

Szerk: lehetne még pörögni azon, hogy a Windows64 miért lett LLP64, szemben a Unix-szerű rendszerekkel, amik LP64 tipusúak, de talán egy kicsit már késő lenne.

A hozzászóláshoz be kell jelentkezni

Nekem jött és jön egy csomó bounce ilyen tartalommal, gyanúsan Exchange szerverek, ettől lehet?

Remote Server returned '400 4.4.7 Message delayed'

https://iotguru.cloud

A hozzászóláshoz be kell jelentkezni

igen

A hozzászóláshoz be kell jelentkezni

btw

https://www.alitajran.com/exchange-mail-flow-breaks/#h-solution-to-exch…

Itt van infó + fix MS-től. Akit érint. Nálam 1 helyen volt érintett. Tegnap óta bypass-ra volt rakva a filter ezen része. Most megy fel a fix + reenable.

btw kis kiegészítés: https://techcommunity.microsoft.com/t5/exchange-team-blog/email-stuck-i…

ps1.: Az általam érintett rendszeren tökéletesen ment a fix. bypass filter false -ra visszarakva, levelek jönnek-mennek .. Eddig :) Nem egy nagyforgalmú szerverről volt szó szerencsére.