Fórumok
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)
Hozzászólások
Mi lesz a fix, konvertálják unsigned long-ra? Az még 21 év, akkor már úgyse lesz támogatott.
Kinek van pénze Exchange 2019-re? 🤣 Office 365 meg még mindig 2016, ha jól tudom.
trey @ gépház
egyetemeknek :) mivel nekik kb ingyen van...
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
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.
Szerintem te az outlookrol beszelsz.
Domain, tárhely és webes megoldások: aWh
Szerintem is.
trey @ gépház
Yup, lehet. "Office" - erről nekem a desktop jutott eszembe, sorry :)
<-------
You can't grep on dead trees.
Exchange 2016 is produkálja ... :(
Államigazgatás, ott kb mindegy mennyibe kerül, csak on-premise legyen.
mi ez, Y2k22 bug?
Komolyan így tárol valaki dátumot? Semmi logikus haszna nincs
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.
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.
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)
Szokas, de nem kotelezo. Siman inkrementalhatod is es kesz.
Domain, tárhely és webes megoldások: aWh
Node az csak azért dátum, mert így szokás. Amúgy lehetne akár 1 is az első. :)
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
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.
Nekem jött és jön egy csomó bounce ilyen tartalommal, gyanúsan Exchange szerverek, ettől lehet?
https://iotguru.cloud
igen
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.
én azt hittem hogy minden szilveszter előtt előre tesztelnek minden szolgáltatást hogy jan1 után is működni fog-e
legalábbis ez akkora rizikó hogy mindenképp kéne szerintem, és mégis benéznek egy ilyet
Persze. Indiai "mérnökökkel", jah.
Gábriel Ákos