Microsoft verkoopt straks securityupdates voor oude Exchange- en Skype-servers

Microsoft schuift de supportdeadline op voor oude Exchange- en Skype-servers. Het bedrijf biedt betaalde extra support na 14 oktober dit jaar. Dit geldt voor klanten die nog werken met versies 2016 of 2019 van Exchange of versies 2015 en 2019 van Skype for Business.

Microsoft kondigde deze verlenging van de ondersteuningsperiode voor die serverproducten gisteren aan. De ontwikkelteams achter Exchange Server en Skype for Business lichten het Extended Security Update-programma (ESU) toe in twee blogposts over deze producten. De verlenging geldt alleen voor beveiligingsupdates en is vanaf 1 augustus beschikbaar.

Klanten van Microsoft die nog de oudere versies van die serversoftware gebruiken, moeten contact opnemen met hun accountteam bij de leverancier. Het Exchange-team stelt dat sommige klanten zijn begonnen met de migratie naar de nieuwe Subscription Edition (SE) van die mail- en agendasoftware, maar dat deze overstap meer tijd nodig heeft. Het gaat om ‘een paar extra maanden’ om de migraties af te ronden.

De abonnementsversie van Exchange Server is iets meer dan een jaar geleden aangekondigd. De release stond toen gepland vlak voor het einde van ondersteuningsperiode van de voorgangers, waardoor klanten weinig migratietijd hadden. Begin april dit jaar kondigde Microsoft prijsverhogingen aan voor zijn on-premises draaiende standalone serversoftware, zoals Exchange Server, Skype for Business en SharePoint Server. Die prijsverhoging per 1 juli is volgens Microsoft om 'doorlopend onderhoud en ondersteuning' te kunnen blijven bieden.

Ook gebruikers van Skype for Business hebben enkele maanden uitloop, meldt het team achter dat zakelijke Microsoft-product. Voor beide producten verzekert het bedrijf dat er geen tweede ESU-periode komt. Na 14 april 2026 komen er gegarandeerd geen updates meer voor deze oudere serversoftware.

Officieel is dit ESU-aanbod voor Exchange en Skype for Business geen verlenging van de supportcyclus, benadrukt Microsoft. Beide producten vallen per 14 oktober 2025 buiten de ondersteuning. Het tegen betaling verstrekken van securityupdates is alleen bedoeld als tijdelijke oplossing voor klanten die hun servermigraties niet op tijd af weten te krijgen.

Voor klanten die kiezen voor deze betaalde extra support is er geen garantie dat ze in die periode daadwerkelijk securityupdates ontvangen. Als er kwetsbaarheden aan de orde zijn, oordeelt het Microsoft Security Response Center (MSRC) of die kritiek of belangrijk zijn. Alleen dan krijgen uitsluitend ESU-klanten securityupdates; deze komen niet openbaar uit.

Microsoft adviseert klanten niet te vertrouwen op dit ESU-aanbod, maar hun organisaties op tijd te migreren naar de SE-uitvoeringen van Exchange Server en Skype for Business.

Door Jasper Bakker

Nieuwsredacteur

17-07-2025 • 10:40

39

Reacties (39)

39
38
14
2
0
21
Wijzig sortering
Begrijpelijk dat Microsoft dit doet, maar het voelt ook een beetje als dubbel beleid. Aan de ene kant verhogen ze de druk om te migreren naar Subscription Edition, en aan de andere kant bieden ze tegen betaling toch nog uitstel. Voor sommige organisaties is dat welkom, zeker als de migratie vertraging heeft opgelopen, maar je zit dan wel aan een betaalmodel zonder garantie op updates. Uiteindelijk blijft het signaal duidelijk: on-premises support verdwijnt langzaam en wie achterloopt, betaalt de rekening.
Het migratiewindow is zeer kort. 1 juli is Exchange S.E. RTM uitgekomen. Exchange 2019 CU16 gaat EoL op 14 oktober. Naar mijn weten het korste migratiewindow ooit voor Exchange. Ik was en ben vol bezig met de migratie. Ik heb inmiddels 8 servers geprepped voor de installatie en configuratie. Geen in-place upgrades dit keer gezien wij momenteel nog op een ouder Windows Server OS zitten.
Nou de huidige tech-stack voor on-premise verdwijnt. Naar mate de cloud door ontwikkelt en makkelijker wordt. Gaat die straks ook als nieuwe tech-stack voor on-premise draaien.
Niet straks, on premise office 365 is net aangekondigd
Aangekondigd, maar niet wat voor haken en ogen (en kosten) daaraan zitten. Dat zal ongetwijfeld nog wel tegenvallen.

Voor o365 local is sowieso al azure local nodig, hoeveel bedrijven hebben dat draaien?
Oh, ik hoor dit voor het eerst. Wat houd dat in? Ik kan er niet zoveel over vinden...
Updates verschijnen nu ook al onregelmatig. Er moet wel aanleiding zijn om iets te fixen en een SU uit te brengen, los va nde hele cyclus die dit met zich meebrengt.
Zelfde beleid als onze tabakstax: je moet er vanaf maar als je het echt wil, hier heb je (steeds hogere) prijzen!

Zo ontmoedig je zonder te verbieden.
Het is GEEN verlenging van support; het is 6 maanden recht op eventueel uitgebrachte security updates.
Klinkt mij als een vorm van support :)
Je hoeft in die periode geen contact te zoeken met support voor problemen of andere zaken. Dat is, tenzij ze betrekking hebben op een SU die in de ESU periode is uitgebracht. Dus: Geen support.
Dat is, tenzij ze betrekking hebben op een SU die in de ESU periode is uitgebracht
Klinkt mij als support. :) Dat de support beperkt is, maakt geen enkele zak uit.
Organisaties kijken daar toch wat anders tegenaan.
Als dit jouw interpretatie is, verder prima.
Organisaties zouden zich al lang weg bewogen moeten hebben van zulk verouderde producten
Als iets werkt blijft een bedrijf daar zo lang mogelijk mee werken. Er is een reden dat er nig systemen met xp of zelfs W95 ergens nog lopen. En kijk naar Japan en floppydisks (geen software) wat nu eindelijk de dodo’s achteraan gaat.
Dat was ooit zo, maar tegenwoordig moet je als bedrijf security steeds hoger in het vaandel hebben. Data lekken, hacks etc.... Het excuus dat upgraden duur is kom je niet mee weg.

Dus steeds meer organisaties zorgen dat ze meekomen met de supported releases waar security nog gepatched word. Mijn werkgever ondersteund ook organisaties die echt niet willen upgraden, maar die moeten wel tekenen dat ze willens en wetens een behoorlijk security risk nemen. Dat kan dan niet op ons neerkomen.

We hebben ook steeds meer risk monitoring tools draaien en het eerste waar die over schreeuwen is wel end of life.

En japan was niet de enige met in zijn (overheid) infra een floppy probleem, de VS kan er ook wat van en verschillende andere landen. Maar dat gaat vaak over infrastructuur al dan niet militair. Niet voor commerciële bedrijven.
Het excuus dat upgraden duur is kom je niet mee weg.
Dit blijft een lastige. Er zit vaak een heel verhaal omheen.

Even een puur hypothetische situatie:

Stel je bent een bedrijf met op maat gemaakte software, of ultra-specifieke software, geschreven in COBOL, enz. Laten we zeggen software van een verzekeraar die een bepaald type verzekeringen aanbiedt voor hypotheekverstrekkers van (voormalig) spaarhypotheken. Dus echt heel specifiek. Je hebt maar een handje vol klanten (een paar banken en andere hypotheekverstrekkers). Het verzekeringsproduct zit in een op maat gemaakte applicatie, want alleen Nederland heeft dit type hypotheken en moeten verzekerd kunnen worden.

Je product is eindig (want er worden geen nieuwe spaarhypotheken meer verkocht, dus verzekeren is over een x-aantal jaar niet meer nodig), het heeft vrijwel geen onderhoud meer, want het is heel oud, er gebeurd in de praktijk vrij weinig en de bugs zijn er wel uit over de jaren heen. Enige probleem is, is dat het alleen maar onder AIX 7.2 draait. AIX 7.2 is ondertussen out of support.
Het migreren van de bestaande applicatie naar AIX 7.3 of hoger, of wat brutaler naar Linux kost 7.500.000 euro.

Echter. Je bedrijf heeft ook recentelijk geïnvesteerd in een ander product, waar je in theorie de functionaliteit van je verzekeringsproduct ook in kunt stoppen mettertijd (dus niet de applicatie migreren, maar de functie migreren). Daar heb je al 180.000.000 in gestoken voor al je andere verzekeringsproducten. Maar om een één of andere reden lukt het moeilijk, door je softwareleverancier om die functie in die nieuwe applicatie te stoppen, maar ze zijn er wel mee bezig, en je hebt de 'garantie' dat het over 9 maanden is gelukt. Alleen zeiden ze dat vorig jaar ook.

Wat ga je dan doen. 7,5 miljoen investeren? Of pappen en nathouden totdat het wel in die applicatie zit, en potentieel minder veiligheid tijdelijk accepteren. (je systeem is niet internet verbonden enz.) Dan moet er dus een afweging gemaakt worden.

Wat is het werkelijke risico voor 'aanvallen van buitenaf'. Is de hardware nog beschikbaar wanneer het faalt. Ondersteund je OS nog de juiste versleutelingsalgoritmen om wel met de rest van je bedrijf te kunnen communiceren. Kun je eventuele kwetsbaarheden via derdepartijsoftware afwenden, enz, enz, enz, enz. Enerzijds is het goed geld (die 7,5 miljoen), anderzijds, wanneer het misgaat, ben je gigantisch het bokkie, en kost het je een veelvoud. Alleen de kans dat het misgaat is gigantisch klein.

Dus het is een gigantisch lastige afweging.


Nogmaals. Bovenstaande is puur hypothetisch. Er is geen goed antwoord (want er spelen natuurlijk ook nog 200 andere dingen mee, en onderschat ook de interne politiek niet, enz.)
Die hypotetische situatie zal echt voorkomen. typisch sluiten wij dat soort systemen op in een eigen netwerkje, vaak eentje dat uit staat tenzij de gegevens nodig zijn. Dat is het beste dat je kan doen op zo een moment.

Er zijn altijd uitzonderingen en bijzondere situatie. Maar als we een andere hypotetische situatie nemen. Je hebt een maatwerk applicatie geschreven voor windows 95 die actief elke dag word gebruikt voor je diensten. Er zit een ton aan klantinformatie in en wellicht is er een internet portal. Upgraden kost een paar miljoen..noem maar wat.

Wil je dat dan niet doen? Wil je klanten echt vertellen dat je security van hun data niet belangrijk vind? Je kosten van die upgrade heb je als het goed is al lang in je productprijs opgevangen. Je wist bij het bouwen al dat je ooit moest upgraden, de wereld staat niet stil.

Bij blijven hoort gewoon bij de bedrijfslasten. Je mag best de levensduur van een platform afwachten. Maar je moet naar de volgende versie zijn voor het security support verliest en liefst ruim daarvoor. De support termijnen zijn rustig 10 jaar. Dat is meer dan zat tijd.
In jouw concrete voorbeeld is er al een heel ander 'oppervlakterisico' (namelijk internet-verbonden), wat de hele dynamiek anders maakt dan mijn voorbeeld.

Wat ik al schreef op het einde. Er is niet één goed antwoord. Er spelen zoveel zaken mee.

N.B. Wanneer je 'nu' een applicatie schrijft (laat schrijven), houd je daar zeker rekening mee. In het Windows95-tijdperk was dat heel anders. Toen waren we toch heel erg aan het cowboyen :-) Toen hadden bedrijven geen 1,5 -2,5(virtuele) server per ontwikkelaar/tester staan. :) Toen was je al blij als je een een acceptatieomgeving had, naast je ontwikkelomgeving.

En vervolgens roest het er ook in. Uiteraard geen excuus, maar het blijven afwegingen. En het gaat al veel beter dan vroeger.
Ook nu wordt daar maar weinig rekening mee gehouden. Je neemt een SaaS dienst af, deze is open een heeft de mogelijkheid allerlei plugins van externen te gebruiken. Zelf maak je ook customizations in de backend database specifiek voor jouw bedrijf.

Bedrijf gaat over naar nieuwe versies, nieuwe technieken. Deel van de plugins die je gebruikt zijn niet compatible en ook je eigen customizations moet je handmatig overzetten. Daar heb je al een probleem.

Nou gaat die SaaS dienst ineens 2x zoveel vragen voor de subscriptie. Eigenlijk wil je weg en naar een andere SaaS dienst. Data is wel te exporteren, maar hoe ga je al die customized plugins en data vervolgens in een nieuwe SaaS dienst krijgen? Wie gaat die migratie doen en hoeveel gaat het kosten? Hoe lang gaat het duren?

Ik kan je nu al vertellen dat er vrij veel bedrijven zijn die dit probleem op dit moment hebben.
Klopt. De 'exit-strategie' van SaaS-diensten is op het moment een ding. Tegenwoordig koop je, jezelf in, in een cloud-organisatie, waar je effectief in vast komt te zitten.
Ik ken bedrijven die nog steeds internet-facing applicaties hebben draaien gecompileerd op Java 6 en ondergebracht in Wildfly 9. Daar is wat betreft security nooit een issue op gevonden. Niet op black- en greybox pentests door derden en niet met het verkrijgen van een DigiD 2.0-assurances voor Logius. Wat betreft security is daar dus niets loos (de openstaande CVEs aantoonbaar niet van toepassing of aantoonbaar effectief gemitigeerd).

Het wordt een ander verhaal wanneer de klant nieuwe eisen en wensen gaat introduceren voor de applicatie; dan gaat een peperdure migratie plaatsvinden naar een nieuwer platform. Legacy meuk kan prima veilig zijn qua security door mitigerende maatregelen en een goede infrastructuur. Restrisico is voor de eigenaar van de applicatie -- en dat restrisico is misschien nog hoger bij state of the art frameworks en libraries.
Ik begrijp niet dat organisaties niet klaar zijn om naar de nieuwe SE over te stappen. Dit is reeds meer dan een jaar terug aangekondigd van hoe dit in zijn werk zou gaan, namelijk gewoon een aanpassing van de licentiesleutel op je Exchange 2019 daar Exchange 2019 en Exchange SE initieel functioneel identiek zijn. Ook dat je slechts enkele maanden zou hebben om die omschakeling te maken was al duidelijk van toen het nog Exchange vNext noemde. De release stond altijd voor de zomer van dit jaar gepland met een EOL van 2016 en 2019 in Oktober van dit jaar.
Niet elk bedrijf heeft de resources om tussen de zomer en oktober alles in orde te krijgen. Imo was microsoft heel laat met alle informatie en kreeg je maar weinig tijd.
Dat is dus net wat ik zeg: de manier waarop is al meer dan een jaar bekend, je hebt meer dan een jaar gehad om je voor te bereiden. Als je op een jaar tijd niet kunt voorbereiden, dan moet je je toch ernstige vragen stellen over of je wel in staat bent je infrastructuur goed te onderhouden.
Het is een jaar op voorhand aangekondigd dat het ging veranderen, maar de details kwamen afaik veel later , wat niet handig is als je een project wil inplannen. Los daarvan, je zou verbaasd zijn hoe traag bedrijven zijn, genoeg bedrijven die nog moeten beginnen met de implementatie van pebbol peppol in hun ERP systeem ondanks de deadline van 2026. 😉

[Reactie gewijzigd door IStealYourGun op 17 juli 2025 14:12]

Je bedoeld vast Peppol, in België al verplicht voor facturatie richting de overheid.
Volledig mee akkoord, zeker als alles samenkomt, interne of externe resources zijn niet onbeperkt beschikbaar. Zeker niet met het verlof voor de meeste nu. En dan komt altijd de hamvraag, kun je dat er niet tussennemen. Ja... Maar niet 20.

Tevens spelen er wel nog andere zaken, zeker in grote(re) bedrijven maar ook bij de kleine(re). Bij verschillende van mijn klanten is er altijd grote discussie als er iets moet veranderd worden, waarom moet dat, het werkt toch gewoon, is die kost het wel waard. Het is toch maar email, jep totdat het niet meer werkt. Er is net een grote (marketing) campagne bezig, mag 0 downtime hebben, ik ben op verlof maar wil erbij zijn. Dat kan allemaal perfect wel maar het vergt wat tijd en moet voorbereid worden. Als je dan -tig hebt die allemaal tegelijk komen met reeds een volle planning dan moet er geschoven worden, maar dan is er altijd wel iets. Dat is niet negatief bedoeld maar het vergt soms wel wat jongleren. Soms ligt het ook niet in onze handen. Ik kan adviseren, presentatie's maken, management overtuigen met allerlei criteria en de meeste gaan daar wel in mee, sommige niet.

De beste twee die ik tot nu toe tegengekomen ben zijn.

Een oud(er) SAP systeem die in azure staat gebruikt de on-premise exchange (2016 geloof ik) om alle mails te versturen. En wanneer ik zeg alles, is het echt alles, domiciliëring, contactgegevens, facturen, scans, rapporten, leveringen, stock, you name it. Er is een project gaande om een nieuwe installatie te doen, kleine drie jaar al en dus stond die exchange on hold want alles ging nieuw opgezet worden ernaast. De leverancier aangeschreven, hoop delay, niemand wist van iets, in verlof, persoon die origineel de code geschreven heeft werkt er niet meer, etc... Het resultaat was, tgochja, dat is allemaal custom code en het IP van de exchange is overal hardcoded, we schatten 300 mandagen (dit is geen grap) om alles te veranderen en we doen dit enkel in regie... Conclusie: we gaan dat ding 'voorlopig' laten staan. Binnen vijf jaar ga ik de discussie nog eens aan ;).

De beste vanal, ticketing system. Leverancier wilt dat er een upgrade wordt gedaan. nieuwe en secure protocollen worden niet ondersteund bij de huidige installatie. Klant wou geen upgrade doen, heeft uiteindelijk een ander systeem aangekocht een kleine twee jaar geleden en er een student opgezet... Uiteraard draait dat nog steeds niet. In mei dit jaar is er een nieuwe CTIO gekomen, die heeft de huidige IT manager ontslagen en een oude bekende van hem binnengehaald die op zijn beurt beslissingen nam, AS400, dat is slecht = buiten. Unifi telefoon, da's een slecht merk, alles vervangen. HPe Aruba switches, dat is veel te duur, alles buiten. Watchguard firewalls, da's slecht materiaal, alles naar fortinet, veel beter. Exact voor facturatie, CRM dynamics is veel beter. En dan krijg je een wirwar aan projecten waar iedereen en niemand aan werkt. Mag je nog met de beste argumenten komen voor exchange, dat heeft geen prioriteit. Dit is een heel specifiek geval maar er zijn wel bedrijven waar er momenteel andere en grotere projecten aan de gang zijn. Nu het beste vanal, dit ticketing systeem gebruikt uiteraard de lokal exchange en men is tot de conclusie gekomen dat na de student vertrokken is - een maand ofzo - er niemand meer aan dit product gewerkt heeft. Je houdt dit niet voor mogelijk.

Als positieve noot, hoewel in mijn mening dit ook veel telaat aangekondigd werd geeft het wel een goede vibe en een opportuniteit om wat zaken te veranderen als we toch bezig zijn. Aanschrijven van leveranciers, overzetten naar cloud of op zijn minst toch de connector/email. Gedaan met allow relay anonymous all/all. Het is deels alsof iemand de deur intrapt en iedereen van zijn stoel sprint.
Omdat niet alle bedrijven dit kunnen betalen.

Of omdat er een gebrek is aan human resources.

Of omdat andere projecten belangrijker zijn dan een on-prem Exchange server.

Toen Exchange SE gelanceerd noemde ik het al meteen Exchange Super Expensive.

Dit is door Microsoft een gouden zet geweest om nog meer mensen naar Microsoft 365 te krijgen. Door het on-prem model duurder te maken dan het cloud model. En waarom zou je nog een eigen exchange servers draaien als 80 procent van alle email toch al via Google en Microsoft worden afgehandeld. Ik ben in mijn carrière als IT'er ooit maar 1 iemand tegen gekomen die on-prem exchange als product echt leuk vond. Verder is email/agenda een beetje het zelfde al water uit de kraan. Het moet gewoon werken ;)
Natuurlijk is dit een zet om bedrijven naar de cloud te duwen.

Maar als je gebruik wenst te blijven maken van een Exchange in je eigen omgeving, dan wist je al meer dan een jaar dat dit er aan zat te komen, en dan wist je al heel die tijd dat je een Exchange 2019 zult nodig hebben die je dan inline kunt upgraden naar Exchange SE.

Als je nu nog helemaal moet beginnen aan die conversie, dan heb je gewoon zitten slapen. En ik zie dat spijtig genoeg ook te vaak gebeuren. Beheerders die geen idee hebben wat de roadmap is van de producten die ze ondersteunen. Ondanks dat de EOL van Exchange 2016 en 2019 al meerdere jaren bekend is.

Dat heeft niets meer te maken met niet kunnen betalen (want dan ga je ook niet voor die ESU gaan) of een gebrek aan resources, want dan ga je met dat half jaar het ook niet trekken. En een product waarvan je op de dag dat je het installeert al van weet wanneer de EOL is dan kan je het ook niet over prioriteiten hebben, want je weet dat het er aan komt.

Het enige wat ik mij dan nog kan indenken zijn dus slechte systeembeheerders die de roadmap van hun producten niet volgen.
Je aanname dat dit aan beheer ligt is echt de verkeerde. Ik doe managed services voor meerdere bedrijven. Zelfs 1 waar we al 3 jaar aangeven dat we alles naar de cloud om willen zetten omdat dit er idd al heel lang aan zit te komen. Maar er is gewoon geen geld bij die hut. Daarnaast zitten ze echt niet te wachten op een maandelijkse subscription.

Dan ligt het dus niet aan beheer maar aan upper management van de customer.

En als het EOL is dan is er straks ineens paniek. En ik kan je op een briefje geven. Dan is er wel geld en moet beheer ineens gaan rennen.
Omdat het plaatje groter is dan het technisch vlak van omzetting, vanuit financieel aspect ga je van een investering naar een operationale kosten (CAPEX naar OPEX) plus de omzetting zelf, afhankelijk van omvang en budget, bedrijven waar het allemaal 'niet zo voor de wind' gaat, zal dit een flinke uitdaging zijn geweeest. En vanwege de (behoorlijke) stijging die SE meebracht, zullen er ook meteen projecten zijn gekomen om van onpremise naar cloud te gaan, die simpelweg SE overslaan en meteen 365 gaan doen.

Als je dan als bonus ook nog systemen heb draaien die omgezet moeten worden (met bijbehorende kosten), dan is het niet zo raar dat er veel bedrijven zijn die nog niet over (kunnen) gaan.
Als ik het goed begrepen heb allemaal is de SE editie een soort CU op je bestaande 2019 Exchange met een nieuwe licensekey. Kan toch niet heel complex zijn allemaal zou je denken.

Ga ik wel eerlijk bij toegeven dat ik de transitie periode ook wat gebrekkig vond, want volgens mij kun je momenteel SE nog niet kopen? Als dat rond dezelfde tijd beschikbaar komt zit je in grote organisaties vaak met logge inkoop processen etc dus dan is de eerder gestelde overgang misschien wat aan de krappe kant.
Je kan inderdaad gewoon een in place update draaien, zelfs geen nieuwe license key nodig.

Maar veel on premise omgevingen vervangen dan graag ook het onderliggende OS, de hardware, enz. Dus nieuwe server bouwen, en mailboxen overzetten. Dat kan wel effe duren.
Nu MS voor alles verlengde ondersteuning verkoopt, hadden ze dit niet beter voor hun originele Windows 10 Mail app kunnen uitbrengen? Hier heb ik oprecht wel geld voor over gezien Outlook zo vreselijk bloated is en lelijk oogt tov Mail. En het lijkt mij een makkelijk te onderhouden applicatie gezien dit gewoon Outlook met een andere schil is.

Wie kan Skype of Exchange überhaupt nog iets bouten?
Wijze woorden hou het simpel dan is het veilig
Bor Coördinator Frontpage Admins / FP Powermod @Zynth17 juli 2025 11:52
Een 100% veilig product bestaat simpelweg niet. 100% veiligheid is nooit bereikbaar. Er zijn altijd kwetsbaarheden, zeker in softwareland. Deze kwetsbaarheden zijn natuurlijk geen businessmodel.

[Reactie gewijzigd door Bor op 17 juli 2025 11:53]

De MS producten gelijken door de jaren meer op een gatenkaas mijn gedacht ;-)

Nu nog moeten dokken om de gaten te blijven dichten? Is toch een plaaster op een houten been...


Om te kunnen reageren moet je ingelogd zijn