Microsoft brengt patch voor Exchange Server opnieuw uit na eerdere errors

Microsoft heeft de patches voor Exchange Server opnieuw uitgebracht. Die patches kwamen vorige week tijdens Patch Tuesday naar buiten, maar bleken op niet-Engelstalige besturingssystemen problemen op te leveren waardoor Exchange niet meer goed werkte.

Het gaat om de Exchange Server Security Updates die Microsoft op 8 augustus uitbracht tijdens de maandelijkse patchronde Patch Tuesday. Het bedrijf schrijft nu in een ondersteuningsdocument dat het die nog een keer uitbrengt, maar dan zonder de problemen die eerder ontstonden. Microsoft hernoemt de oude patch Aug SUv1 en de nieuwe Aug SUv2. Beheerders van Exchange Server zouden die moeten installeren als ze eerder problemen hadden met SUv1. Voor servers waar de installatie automatisch gaat en geen problemen worden gedetecteerd, wordt SUv2 automatisch gedownload, zodat beheerders die kunnen installeren.

Tijdens de vorige patchronde bleek er al een ernstig probleem in SUv1 te zitten. Dat gebeurt op Exchange Server-systemen waar een niet-Engelstalig besturingssysteem op draaide. Op die systemen bleek de set-up in veel gevallen onverwacht te stoppen. Daardoor was het niet meer mogelijk Exchange te gebruiken.

Microsoft zegt dat de patch de lokalisatieproblemen oplost. Eerder had het bedrijf al een workaround beschreven waardoor de foutieve update werd teruggerold. Beheerders zouden de nieuwe release alsnog moeten installeren, schrijft Microsoft.

Reacties (34)

[itlee]

Hou even rekening mee, als je een CAS opstelling hebt draaien komt de suv2 update niet automatisch mee. je moet deze handmatig downloaden. (voor de rest thnx tweakers dat jullie hier aandacht aan besteden.)

het orginele artikel van 8 aug:
https://techcommunity.mic...rity-updates/ba-p/3892811

en hier het rerelease artikel van MS:
https://techcommunity.mic...urity-update/ba-p/3900025

Link voor exchange 2016 cu23
https://www.microsoft.com...ad/details.aspx?id=105536

Link voor Exchange 2019 cu13
https://www.microsoft.com...5a-43b4-a258-2c97a910b87f

[Reactie gewijzigd door itlee op 23 juli 2024 22:45]

[WhiteDog]

Je zou denken dat ze bij Microsoft na 40 jaar OS'en bouwen het stukje lokalisatie een tijdzones voor elkaar hebben... kan uit ervaring vertellen dat het alleen maar erger wordt.

Wel benieuwd wie zijn Windows Server OS niet in het Engels heeft geïnstalleerd 🤷‍♂️

[maevian]

Inderdaad, zelf onze terminal servers zijn in het Engels (gebruikers hun profiel laat natuurlijk wel gewoon het Nederlandse taalpakket).
Is ook veel makkelijker om documentatie te vinden, want die ene setting noemt toch net wat anders in het Nederlands.

Maar grotere vraag, wie draait er exchange nu nog onprem?

[Reactie gewijzigd door maevian op 23 juli 2024 22:45]

[Rataplan_]

Wij. We hosten veel remote werkplekken. En terwijl er natuurlijk wel een verschuiving plaats vindt, zijn veel klanten nog op onze onpremise exchange dag. Omdat ze dan exact weten waar hun data staat bv. Voorspelbare performance, we draaien voor de meesten gewoon online mode, wat met on-prem ook prima kan en daardoor geen gedoe met offline caching, gedoe met fslogix en noem maar op. RDS werkt prima met Exchange Online, maar het brengt wel extra complexiteit met zich mee. En ik geef toe, laatste maanden gaat het beter met Exchange Online, maar we hebben perioden gehad waarbij de performance echt om te janken was, de search weer eens niet werkt, de dienst gewoon plat was. Natuurlijk is onze on-prem niet vrij van issues, maar door de natuurlijke veel kleinere schaal dan bij MS in absolute getallen veel minder problemen dan met EXO. En buiten dat, áls er een issue is, kunnen we zelf weten wanneer het weer op is, want alles zelf in de hand. Bij een storing bij MS kan je alleen afwachten. Niet erg, gewoon andere mindset, maar de klanten bellen ons wel om uitleg.
M.a.w. wat ons betreft zijn on-premise oplossingen nog lang niet van de baan.
[Edit] typo's

[Reactie gewijzigd door Rataplan_ op 23 juli 2024 22:45]

[Dennisb1]

Wij, bewust uit data veiligheid o.a.

[powerboat]

Me2

[Pharos1985]

In theorie nog steeds nodig indien je uw users synct van onprem (ik weet wel: je kan ook nog die attributen in AD gaan aanpassen e.d.). Maar indien je met archiving zit en dergelijke, of met shared mailboxes, wordt het een grote uitdaging om een mailbox die onprem een user account heeft, om te zetten naar een shared mbx in 365.

Dat laatste moet in theorie onprem gebeuren: je kan dat in de cloud doen, maar beter is om dat toch gewoon lokaal op de onprem Exchange doen.
Je krijgt zelfs gratis Exchange 2019 indien je 365 abo's hebt (misschien enkel de enterprise 365 lijn, dat weet ik niet vanbuiten). Die gratis Exchange mag je uiteraard geen mbx'en op hosten.

[ETH0.1]

Voor ons is dat vrij gebruikelijk en vaak geen probleem. Echter zijn bijvoorbeeld de Duitsers, Fransen en Italianen behoorlijk volhardend in het gebruiken van de niet Engelse varianten

[Cambionn]

Toetsenbordinstellingen zijn net zo erg. Ik heb nog nooit een combinatie van reguliere inputmethods als US int. of in mijn geval UK samen met IMEs soepel gehad en zo als ik wou. Maakt ook niet uit of het de officiele Windows IMEs zijn of third party IMEs. Wel eens in de zoveel updates dat hij anders vervelend doet, maar nooit heeft het gewoon gewerkt zoals het zou moeten.

Zelfs nu weigert hij nog gewoon op mijn UK op te starten ondanks dat die als default staat. Nee altijd in de secundaire Japanse of Chineese input method met de IME aan, dus als je hem niet terug zet tiep je leuke karakters. En dit is nog een van de minst erge issues die ik heb gehad...

Dit soort problemen nooit op m'n Linux gehad. Maar na een paar jaar klooien heb de hoop om het op mijn Windows machines te fixen inmiddels opgegeven.

[wiseger]

Vind je het echt onbegrijpelijk dat mensen in China, Latijns Amerika en dergelijke niet altijd voor Engels als installatie taal kiezen?

[Dennisb1]

Wel benieuwd wie zijn Windows Server OS niet in het Engels heeft geïnstalleerd 🤷‍♂️

Voor Exchange lijkt mij dit ook stug maar voor een Terminal Server is dit bijv. redelijk gewoon om te doen voor de user experience (al dan niet met als extra taalpakket).

[Reactie gewijzigd door Dennisb1 op 23 juli 2024 22:45]

[SkiFan]

Gewoon Engels installeren en dan de language pack toevoegen. Lijkt me stug dat een organisatie inmiddels géén engelstalige medewerkers heeft.

[[Roland]]

Buiten Nederland natuurlijk bosjes mensen die geen Engels spreken.

Daarbij ook overheden die verplichten dat software in de 'eigen' taal wordt gebruikt.

Denk dat je in Duitsland en Frankrijk heel veel servers vind in de het Duits en Frans.

[Dennisb1]

Het gaat er niet om of een medewerker wel of geen Engels kan. Het gaat om de UX voor een persoon.

[SkiFan]

Ja, en die kun je dus prima middels een languagepack toevoegen. Heb je nog steeds een US Windows, maar hij spreekt wel gewoon alle talen.

[Dennisb1]

Maar dat zeg ik toch ook in mijn post?

[SkiFan]

Kun je ook precies andersom uitleggen :-)

[nelizmastr]

Hier installeren we idd standaard Windows in het Engels. Waar nodig met een NL taalpakket, dat wel.

[Tonkie1967]

Hoewel je idd zou denken dat MS lokalisatie zo langzamerhand helemaal onder de knie zou hebben is het verre van vlekkeloos. Maar niet alleen een probleem voor MS,:het bedrijf waar ik werk heeft een server-chassis produkt wat goed draaide met optie om zowel lokale timezone in te stellen alsook andere talen te kiezen voor de eindgebruiker. En bij een recente update ging het plotseling fout als je een van de ongeveer 8 "foute" timezones gebruikte: (er zijn bijna 100 opties ) en slechts 8 specifieke timezones gingen fout door een synchronisatie probleem tussen 2 interne onderdelen... Als je als timezone Kiev had ging update fout maar een andere timezone met dezelfde UTC offset waren er geen problemen... Dus ondanks dat alle verschillende UTC offsets waren getest voor de release ging eea toch fout bij hele specifieke timezones, terwijl de timezone functies die gebruikt worden allemaal de standaard functies gebruikten van bekende Linux distros... Moraal van het verhaal: zelfs met veel testen en gebruik maken van standaard distro software kan het toch fout gaan; hoe simpel timezones lijken te zijn is het in de kleine details schokkend ingewikkeld....
(Als bovenstaande uitleg verwarrend is een ander voorbeeld: timezone UK ging bijvoorbeeld fout, maar timezone UTC+0 samen met Europese zomertijd optie werkte prima. Timezone Oekraïne ging fout, zone Polen geen probleem etc... Het betreffende probleem is inmiddels opgelost door binnen 2weken een nieuwe update uit te brengen en de "foute" van de download site te halen...
En voor de klanten in de foute timezones waarvan we wisten dat ze de 'foute' update hadden gedownload is actief contact opgenomen om ze te informeren over het potentiële probleem...(niet iedereen gebruikt de lokale timezone: sommigen gebruiken UTC of gebruiken UTC offset en evt zomertijd ipv de lokale timezone naam en waren dan niet kwetsbaar...
Moraal van het verhaal: timezones zijn veel lastiger dan het lijkt

[Reactie gewijzigd door Tonkie1967 op 23 juli 2024 22:45]

[batjes]

Haha, tijd is 1 van de meest complexe onderwerpen van computers. Het is een ontzettende puinhoop om dit goed te doen.

Laten we voorop stellen dat in de praktijk echt helemaal niemand tijd 100% foutloos heeft toegepast. Dat is praktisch onmogelijk. Linux niet, Windows niet, OSX niet, UNIX niet. Geen van allen.

https://www.youtube.com/watch?v=-5wpm-gesOY

[Reactie gewijzigd door batjes op 23 juli 2024 22:45]

[squaddie]

Het punt met Exchange Server is dat het niet meer wordt ontwikkelt voor lokale installaties, het wordt volledig ontwikkelt voor Exchange Online. Het liefst zou Microsoft de stekker lokale installaties van Exchange server trekken en iedereen die Exchange wil in de Microsoft cloud duwen. Echter er is op dit moment nog te veel weerstand in de markt om dit te realiseren.

De servers die voor Exchange Online gebruikt wordt zullen vrijwel zeker volledig engels geinstalleerd zijn en omdat de ontwikkeling voor online is en de tests ook hierop zijn ingericht kan een naar mijn opinie eenvoudig te vinden probleem ongemerkt in een lokale installatie release terecht komen en daar voor problemen zorgen.

[wiseger]

Het is geen kwestie van teveel weerstand, de kans dat de wereld Microsoft toegang gaat geven tot al haar e-mail verkeer is er simpelweg niet. Daarvoor is de wetgeving in de VS ontoereikend, bedrijven genieten simpelweg te weinig wettelijke bescherming.

Dus zullen bedrijven met bedrijfsgeheimen altijd kiezen voor een lokale, eigen email server.

En dan hebben we het over bedrijven, hebben we het geeneens over overheden.

[maevian]

bedrijfsgeheimen deel je beter niet over e-mail, on-prem of in de cloud.

[wiseger]

Dat gebeurt vanzelf. Informatie over klanten, prospects, verkoopcijfers etc. Gaat dagelijks over de mail.

[michelr]

Onjuist - OnPrem en EXO zijn 2 aparte forks. Er is niet teveel weerstand, er zijn genoeg klanten die om - allerlei redenen - on-prem draaien. Zo is Duitsland bv een groot (Exchange) on-prem bolwerk.

[Blokker_1999]

Hoewel er geen Exchange 2022 is, wordt er wel gewerkt aan Exchange vNext met een verwachte release in 2025. Dit is de volgende versie voor on-prem Exchange en zou dus betekenen dat we minstens tot 2035 on-prem gebruik kunnen blijven maken van Exchange als men dat zou wensen.

Daarnaast zal er ongetwijfeld meer nodig zijn dan enkel en alleen een andere basistaal van het OS. Bugs ontstaan altijd door een combinatie van factoren, en je kan nooit alles testen. elke iunieke combinatie kan verschillen opleveren en soms zelfs de volgorde waarin ogenschijnlijk niet verbonden acties worden genomen kunnen een invloed hebben op het resultaat.

[Unknown Alien]

Er komen structureel problemen met het deployen van MS updates. Ik ben wel nieuwsgierig hoe hun test team dit allemaal testen.

Op een OS met een andere taal is dit een basis test.

[boxlessness]

Waarschijnlijk niet, of deels.
Er zijn dusdanig veel permutaties van settings/configuraties/interdependencies dat het niet realistisch testbaar meer is. Zelfs geautomatiseerd...

Er zijn methodes waar men een subset van alle permutaties van configuraties selecteert om te testen. Wel op een slimme manier zodat zo veel mogelijk configuraties geraakt worden, en vaak wordt ook het risico dat een configuratie breaking changes heeft meegewogen.
Dit verkleint de testset en testtijd, maar laat ook gaten in combinaties die niet getest worden.

Helaas is dit een gevolg van meer software, meer legacy, meer interdependencies, meer en meer.

[michelr]

Dit is categorie slordig en suf: De installatie zocht keihard naar een benaming voor een groep ipv de well-known SID hiervoor te gebruiken (om de actuele naam op te zoeken). En "Network Service" heet in Duitsland, Frankrijk, Japan, etc. toch echt iets anders. Geeft wel aan hoe - als - er getest wordt met niet-Engelstalige omgevingen, maar dat is al jaren een ding.

[SilentDecode]

Ik ben wel nieuwsgierig hoe hun test team dit allemaal testen.

De gebruikers zijn de testteams van MS tegenwoordig. En dat is goed te merken, want alles is in kwaliteit omlaag gegaan, en flink ook.

[Insomnia1988]

Oh dit speelt al een tijdje, ik grapte destijds dat Microsoft zijn test team had ontslagen. Maar dat bleek werkelijkheid te zijn.

Ik vergeet het nooit meer, als ik op printen druk start mijn computer opnieuw op........

[bwerg]

Op een OS met een andere taal is dit een basis test.

Welkom bij exponentiële combinatorische groei in het testen van software. Als deze bug veroorzaakt wordt door een combinatie van twee of drie basisfactoren waarvoor basale tests zijn, en er zijn 1000 basisfactoren (in de praktijk ligt dat aantal waarschijnlijk veel hoger) dan is loopt bijna ondoenlijk om alle combinaties van twee of drie factoren te testen, het aantal uit te voeren testen loopt dan in de miljoenen of miljarden.

Ik zeg niet dat ik zeker weet dat dit geen stomme fout is, maar doen alsof dit duidelijk door slecht testen komt is veel te kort door de bocht.

[Reactie gewijzigd door bwerg op 23 juli 2024 22:45]

[Renegade666]

Ben blij dat ik geen Exchange omgevingen meer heb draaien op locaties, vorig jaar de laatst 2013 uitgezet

Is toch maar een ellende momenteel op dat punt namelijk.