Microsoft waarschuwt voor einde ondersteuning WINS vanaf 2034

Microsoft waarschuwt beheerders dat Windows Internet Name Service, ofwel WINS, in november 2034 definitief niet meer door Windows Server wordt ondersteund. De verouderde dienst voor de verbinding tussen namen en IP-adressen wordt al sinds 2022 niet meer actief ontwikkeld. Tegenwoordig is het gebruik van een domain name system gebruikelijk.

Op een supportpagina laat Microsoft weten dat de functie voor het laatst door Windows Server 2025 uit november 2024 ondersteund werd. Alle toekomstige versies van het serverbesturingssysteem ondersteunen WINS niet meer. De dienst valt daarmee onder de standaardondersteuningslevenscyclus en zal met Windows Server 2025 nog tien jaar beschikbaar blijven. Het bedrijf adviseert beheerders om binnen die periode te migreren naar een hedendaagse DNS-oplossing. WINS heeft sinds 2022 een deprecated-status en wordt dus niet meer actief doorontwikkeld, maar enkel nog onderhouden en ondersteund.

Door Yannick Spinner

Redacteur

24-11-2025 • 21:18

95

Reacties (95)

Sorteer op:

Weergave:

Hoe werkt dit voor thuisnetwerken waar geen DNS aanwezig is? Ik dacht dat WINS daar nog gebruikt werd, of is dat tegenwoordig mDNS oid?
Mijn Synology heeft nog steeds een optie om WINS server te spelen.

Vraag me af wat je daar aan hebt. Moet je het met DHCP ofzo adverteren?
Ja, inderdaad.
Optie 44 voor het opgeven van de server(s)*
Optie 46 voor het ‘node type’, waarmee je de voorkeur-volgorde van resolving-mogelijkheden opgeeft.

*(WINS kan met 1 server maar werd meestal redundant uitgevoerd. In oude NT tijden typisch (maar niet persé) de PDC en BDC’s.
Hoe werkt dit voor thuisnetwerken waar geen DNS aanwezig is?
Broadcast.
Wins is een service die draait op een Windows Server. En heel soms zat het in bepaalde routerfirmware, maar dat waren de OpenWRT-achtigen en niet de normale routers.

Dus eigenlijk had niemand thuis Wins.
Windows heeft geen full mDNS support :-(

Alleen sommige applicaties zoals browsers ondersteunen het.

[Reactie gewijzigd door _--[]--__ op 25 november 2025 09:36]

Hoezo is in een thuisnetwerk geen DNS?
Volgens mij is “router als dns resolver” vrij standaard en daar kun je vaak ook wat lokale dns-entries registreren (fritz.box)
Bor Coördinator Frontpage Admins / FP Powermod @Keypunchie25 november 2025 07:35
DNS binnen een thuisnetwerk waarbij ook de andere machines netjes zijn geregistreerd is niet zo voor de hand liggend als je hier doet voorkomen. Een "router als dns resolver" is inderdaad vrij standaard maar dat richt zich met name op publieke DNS entries en niet op het resolven van hosts op je interne netwerk. Het aantal routers waar je lokale DNS entries kan registreren is niet zo groot en die functie vraagt manuele configuratie wat veel mensen niet doen of kunnen.

[Reactie gewijzigd door Bor op 25 november 2025 07:36]

Een hele hoop spul registreert zich tegenwoordig (met bijvoorbeeld een .local) netjes bij de DNS server. Zeker bij smarthome spul wat vindbaar moet zijn voor setup.
Apparaten als Fritz en andere merken registreren de DHCP-naam + het netwerkdomein in hun lokale resolver. Daar hoef je geen handmatige configuratie voor te doen en daar hoef je ook geen mDNS voor te draaien.

Het is niet de "normale" manier, maar als je het gewend bent is het wel echt een gemis wanneer je naar een goedkopere router gaat die dit niet voor je doet.

Overigens is mDNS op zo'n beetje alles wel beschikbaar tegenwoordig, ook al is Windows-ondersteuning wat beperkt (die werkt niet voor oude applicaties, tenzij je Windows mDNS uitzet en Apple's Bonjour installeert).
DHCP... Automatisch geregistreerd op dns van de router...
De meeste routers hebben deze functie tegenwoordig
Al sinds Windows 2000 is WINS overbodig. Met ADSS hoefde men op domeinen geen WINS meer te gebruiken. Als er nu nog legacy applicaties in gebruik zijn bij bedrijven die WINS vereisen, mogen deze organisaties zich achter de oren krabben waarom ze deze zwaar verouderde en onveilige naamomzetting nog in praktijk houden. Bijzonder dat Microsoft tot aan 2022 nog actief aan WINS gewerkt heeft terwijl ze zelf al in 1999 begonnen aan te geven dat het verouderd en mogelijk onveilig is.
Het wordt echter bij vele grote klanten gebruikt, die veel geld gepompt hebben in de ondersteuning erop. Reden moge duidelijk zijn, beetje vergelijkbaar verhaal als NT4 destijds, dat ook om diverse en uiteenlopende redenen door en voor bedrijven (te?) lang ondersteund is/was. Microsoft stopt niet voor niets "pas" over 9 jaar (!!) echt volledig ermee. ;)

[Reactie gewijzigd door CH4OS op 24 november 2025 21:41]

En waarom gebruiken die dat dan nog ?
Het is echt iets uit de tijd dat mensen nog geen internet/dns hadden....
Omdat zij cruciale systemen hebben die niet zondermeer vervangen kunnen worden en een veel groter fortuin kosten als het om zou vallen.
maar.

Dergelijke systemen zijn kneiteroud, 25 jaar geleden waren ze al niet meer modern.

Ik snap nooit zo goed hoe je dat rijmt met "kritisch systeem" en "kost een fortuin als het stuk gaat"

Like, je bent een archaïsche mummy aan het inbalsemen en aan het beveiligen met allerlei "boobytraps" terwijl je eigenlijk die mummy ook weer ooit moet vervangen, zonder dat je de hele piramide eromheen in laat storten.

Je ben hier als bedrijf al 20 jaar van op de hoogte en je krijgt nu 9 jaar om een vervanger te regelen. Wedden dat er over 9 jaar nog steeds bedrijven te laat zijn?
Jij kijkt er naar vanuit een blik als ICT' er - dan is het klip en klaar. Maar ICT is bij dit soort bedrijven vaak geen core-business.

Ik ken bv. een industriele opstelling die al 25+ jaar automatisch zijn opdrachten en tekeningen ophaalt vanaf een bepaalde server. Die server is relatief moderne hardware en OS, maar die laser met zijn besturing werkte, voor zover ik weet 3 jaar geleden, nog via WINS om die bestanden op te halen. De snijder kost miljoenen, de besturing kun je niet vervangen zonder "alles" te vervangen (tienduizenden euro's). De besturing vervangen levert geen extra (productie-)voordelen op, maar wel veel extra kosten.

De machine is economisch afgeschreven - maar draait nog lekker door zolang het duurt, want ontlast de rest van het machine-park voor het relatief simpele werk. Er is geen enkel business-incentive om daar aan te gaan sleutelen. Maar op hetzelfde moment is dat wel een reden waarom WINS nog draait in dat netwerk.

En ongetwijfeld zijn er heel veel bedrijven met vergelijkbare scenario's.
Maar ICT is bij dit soort bedrijven vaak geen core-business.
ICT is geen core-business, maar die keuze is óók onderdeel van het probleem. Er is bijna geen enkel bedrijf meer wat niet IT als 1-op-1 ondersteuning van zijn core-business heeft. Daarmee is IT gewoon een wezenlijk onderdeel van je bedrijfsvoering.

Ik hoor dit wel vaker, "IT is geen core business" maar als puntje bij paaltje komt kunt je als bedrijf gewoon helemaal niks zonder IT. We weten allemaal dat er wel gewoon een business incentive is om er wat aan te doen in de vorm van risico afdekking. Op een gegeven moment gaat dit gewoon POEF en dan is de vraag of je het op kunt vangen. Een Machine van een miljoen niet vervangen met een verstoring in het verschiet die je minimaal 2 miljoen kost is een bedrijfstechnisch risico waar je in ieder geval een analyse voor wil doen.
De besturing vervangen levert geen extra (productie-)voordelen op
Ja en dat is weer de "kortzichtige" business view die er voor zorgt dat je steeds verder de deur openzet voor potentiële problemen voor je continuïteit.
De snijder kost miljoenen, de besturing kun je niet vervangen zonder "alles" te vervangen (tienduizenden euro's).
Het argument “de machine werkt nog prima, dus we laten het zo” klopt technisch, maar organisatorisch is het een tikkende tijdbom. Je zegt zelf al: het besturingssysteem van de laser is onvervangbaar zonder enorme kosten. Dat betekent dus dat het bedrijf opzettelijk afhankelijk blijft van een component dat door Microsoft al 25 jaar als verouderd, onveilig en end-of-life wordt beschouwd.

Men beschermt een kritische ‘mummy’ met nieuwe servers en brandwerende deuren, maar weigert de sarcofaag ooit te vervangen, terwijl iedereen weet dat het ding een keer verpulvert.

En de geschiedenis leert één ding: over 9 jaar, als WINS echt weg is, staan er inderdaad bedrijven bij Microsoft op de stoep met “spoedvragen”, omdat men dit probleem al sinds 2000 voor zich uitschuift.

Dat betekent niet dat jij ongelijk hebt overigens, dergelijke scenario’s bestaan echt, en soms zijn ze bedrijfseconomisch logisch. Maar het blijft wel een keuze die risico’s opspaart voor later. En dat is waarom dit soort verouderde protocollen zo’n hardnekkig leven leiden.
Je bekijkt het nog steeds vanuit een ICT-standpunt. Wat je zegt is dat er een aanpassing moet gebeuren in het primaire arbeidsproces OMDAT de ICT dat vraagt.

Dat is simpelweg niet de realiteit bij dit soort bedrijven. Vrijwel altijd zou dat andersom moeten zijn: De ICT moet zich maar aanpassen omdat het primaire proces dat vraagt.

Wat jij een kritische "mummy" noemt is niet zo kritisch (men kan in beginsel zonder) maar de extra productie-capaciteit is ideaal om bv. kortere doorlooptijden en "spoedjes" met meer urgentie te doen.

En wat jij zeg over "een component dat door Microsoft al 25 jaar als verouderd, onveilig en end-of-life wordt beschouwd" is natuurlijk maar subjectief. Hoeveel aanvalsvectoren zijn er in de praktijk écht op een machine-netwerk welke gefirewalled is naar buiten en waar men bv. enkel een paar designers bestanden naar laat sturen? Daar kun je prima een afweging in maken, als het veilig genoeg is voor "main-stream" netwerken dan is het waarschijnlijk helemaal prima voor zo'n (airgapped / firewalled) netwerk waar wat machines in draaien.

ICT "eist" veranderingen die geen enkel doel dienen vanuit het perspectief van de primaire arbeidstaak, maar ICT wil het, want update X vereist update Y en dat vereist policy Z en dus werkt die machine niet meer. Zie zoveel van dat soort ICT'ers bij mijn huidige werkgever waar ik ingehuurd wordt door klanten om industriële machines operationeel te houden. De IT'er wil naar Windows 11 voor een machine, ik kijk er naar en concludeer "Het is een 16-bits applicatie, gaat niet werken". Management moet kiezen tussen ICT'er teleurstellen of bv. een machine / opstelling van tonnen uit te faseren, wat denk je wat er gaat gebeuren ?
Wat je zegt is dat er een aanpassing moet gebeuren in het primaire arbeidsproces OMDAT de ICT dat vraagt.
Nee dat zeg ik niet. Ik zeg dat ICT je de optie geeft om je proces te moderniseren en te verbeteren en dat je dan dus soms je proces moet herzien. Dat is een hele andere insteek.

Ik snap je punt, en ik ben het er ook mee eens dat in een ideaal scenario ICT zich schikt naar het primaire proces, zeker in een industriële omgeving waar productie het echte geld verdient. Maar precies daar wringt ’m de schoen: die afhankelijkheid werkt maar één kant op zolang de onderliggende digitale fundamenten (protocollen, OS-versies, netwerkservices) wél een eindige levensduur hebben.

Waar jij in de praktijk, terecht, mee te maken hebt, is: “Het werkt, het is veilig genoeg binnen deze muren, en het levert geld op. Dus laten we het zo houden.”

Maar waar ICT mee te maken heeft is: “Microsoft stopt deze stack over X jaar echt, en dan?”

En dát spanningsveld is precies waarom ik WINS (of 16-bits tooling, of NT4-achtige omgevingen) vergelijk met een ‘mummy’: Niet omdat het waardeloos is, maar omdat het ecosysteem eromheen onvermijdelijk verder rot, ongeacht hoe goed je het lokaal isoleert. Je hebt gelijk dat risico’s op een airgapped of hard-firewalled machinepark veel lager zijn. Maar dat lost het fundamentele probleem niet op:

Je zit vast aan een afhankelijkheid die extern wordt uitgefaseerd, zonder dat jij die lifecycle in de hand hebt.

En ja, voor het management is de keuze vaak simpel:
  • ICT "teleurstellen"
  • of tonnen aan afschrijving slikken
Dan weet je wie verliest.

Mijn punt was vooral: bedrijven wéten dit al 20 jaar, en toch wordt de migratie telkens vooruitgeschoven. Niet omdat het niet kan, maar omdat het geen prioriteit heeft totdat het ineens móet. En dan is paniek duurder dan preventie. Want wat gaan jullie doen als die machine straks echt niet meer verder kan?

Dat maakt WINS niet per se “fout”, maar wel een strategische schuldpost die je vroeg of laat moet aflossen. Hoe goed je hem vandaag ook inpakt.
De IT'er wil naar Windows 11 voor een machine, ik kijk er naar en concludeer "Het is een 16-bits applicatie, gaat niet werken"
Dat is een heel ander verhaal, dan heeft IT gewoon niet z'n due dilligence gedaan en gekeken naar de enige workload die er op zo'n systeem moet draaien. Ik durf er €100 op in te zetten dat de hardware ook niet eens windows 11 draait.
Hoeveel aanvalsvectoren zijn er in de praktijk écht op een machine-netwerk welke gefirewalled is naar buiten en waar men bv. enkel een paar designers bestanden naar laat sturen? Daar kun je prima een afweging in maken, als het veilig genoeg is voor "main-stream" netwerken dan is het waarschijnlijk helemaal prima voor zo'n (airgapped / firewalled) netwerk waar wat machines in draaien.
VEELSTE FUCKING VEEL! Het is echt een krankzinnig aanname die je daar nu doet terwijl de praktijk uitwijst dat het gewoon helemaal niet zo simpel is.
Wat jij een kritische "mummy" noemt is niet zo kritisch (men kan in beginsel zonder).
Je kijkt nu naar het meest gunstige faalscenario, machine stopt, maar je vergeet verder te kijken naar de impact van een total fail. En juist die impact is vele malen groter. Wat jij ziet als een "ach die ene machine die het dan niet doet" kan heel snel uitlopen in een "k*t het hele netwerk ligt plat". En dat is in de praktijk echt al vaak zat gebeurt.

Bij Maersk draaide één enkel intern systeem nog op een oude Windows-stack met verouderde netwerkprotocollen, omdat een modernisering te duur en te risicovol werd gevonden voor het logistieke proces. Dat leek jarenlang geen probleem, totdat NotPetya binnenkwam via precies die legacy-component. In een paar uur lag bijna het hele wereldwijde IT-landschap van Maersk plat: terminals, kantoorautomatisering, scheepsplanning, alles weg. Het bedrijf moest 4.000 servers en 50.000 werkplekken opnieuw opbouwen en verloor meer dan 300 miljoen dollar. Eén oud stukje IT dat “nog prima werkte” werd de duurste downtime in de geschiedenis van de scheepvaart.

https://www.lrqa.com/en/insights/articles/notpetya-ransomware-attack-on-maersk-key-learnings/

De Britse NHS had tientallen medische apparaten die alleen draaiden op Windows XP, omdat de bijbehorende besturingen hardwarematig niet te upgraden waren zonder miljoenenverlies. Dat was jarenlang “veilig genoeg”, want het netwerk was zogenaamd gesegmenteerd. Tot WannaCry toesloeg: niet via internet, maar via interne kwetsbaarheden die door de oude systemen niet te patchen waren. Gevolg: afdelingen dicht, 19.000 afspraken geannuleerd, operaties uitgesteld en een nationale crisis. De apparatuur werkte technisch nog perfect, alleen het digitale fundament eronder niet meer. Dat was voldoende om de zorg stil te leggen.

https://www.england.nhs.uk/long-read/case-study-wannacry-attack/

https://pmc.ncbi.nlm.nih.gov/articles/PMC5461132/

En dan op Neerlandse bodem. Bij VDL Nedcar draaiden de productielijnen op een combinatie van moderne IT-systemen en oudere industriële besturingen die niet eenvoudig geüpdatet konden worden zonder de productie stil te leggen. De fabriek functioneerde prima, zolang alles elkaar maar met rust liet. Tot ransomware in 2022 via een zwakke interne schakel binnenkwam en precies die legacy-componenten raakte die niet gepatcht konden worden. Binnen een dag lagen complete assemblagelijnen stil, werknemers konden niet meer aan de slag en het bedrijf was weken bezig met herstel en het heropbouwen van systemen. De schade liep in de miljoenen. Niet omdat de machines oud waren, maar omdat een verouderde digitale afhankelijkheid uiteindelijk de hele fabriek meesleurde. Totale kosten zijn waarschijnlijk 100 miljoen+

nieuws: Productie VDL Groep is getroffen door een ict-aanval

https://nos.nl/artikel/2404875-vdl-groep-maand-na-digitale-aanval-weer-volledig-in-bedrijf

https://www.security.nl/posting/729158/VDL+Groep+maand+na+cyberaanval+volledig+hersteld+dankzij+back-ups

Dit zijn dus concrete situaties waarin precies de "Airgapped en firewalled" shizzle gewoon keihard gekraakt wordt en dat de komplete continuïteit van je bedrijfsvoering in het geding komt. En ik kan echt honderden van dit soort scenario's bedenken in iedere willekeurige sector die je wil:
  • Industrie: 10-20
  • Zorg: 15-30
  • Energie/nuts: 10-25
  • Transport: 10-20
  • Overheid: 20-40
  • Telecom: 5-10
  • Financieel: 10-20
Ik denk inderdaad als een ICT-er, maar ik kijk ook wel verder dan dat mijn neus lang is. Totale bedrijfsdoel en risico analyse. Dit zijn gewoon dingen waar je je echt achter de oren moet krabben of het het risico waard is. En meestal is het antwoord nee.
Je redeneert vanuit een situatie waar aanzienlijke survivors bias is.

Jij denkt dat het antwoord in de risico-analyse "meestal nee" is omdat je te horen krijgt van alle zaken waar het foutgaat. Maar de veelvoud van systemen die geen enkel problemen opleveren en "meer dan legacy" zijn, hoor je niks van.

In vrijwel iedere serieuze plant waar je gaat rondkijken stikt het van dit soort oplossingen. "Ja die computer moet blijven want daarop programmeren we die oude PLC's", "Die bedient die pomp-installatie die we gebruiken bij de maintenance-cycle iedere 5 jaar" en weet ik het wat voor oude zooi je tegenkomt. MS-DOS applicaties die 1 ding (heel goed) doen, etc etc.
Jij denkt dat het antwoord in de risico-analyse "meestal nee" is omdat je te horen krijgt van alle zaken waar het foutgaat. Maar de veelvoud van systemen die geen enkel problemen opleveren en "meer dan legacy" zijn, hoor je niks van.
Het probleem is dat je nooit van tevoren kunt zeggen of jij diegene bent waar het niet fout gaat. En dan is de risico analyse leuk, maar dan vergeet je de impact analyse mee te nemen.

En voor de meeste systemen die geen enkele problemen opleveren zijn die analyses gewoon niet gemaakt. “Het zal zo’n vaart niet lopen.” Maar alle andere onzichtbare kosten die hierdoor worden gemaakt worden niet meegenomen. ik heb ook systemen ontworpen om dit soort PLC monitoring te doen bijvoorbeeld. De extra kosten die die bedrijven voor de kiezen krijgen doordat ze simpelweg werken met oude meuk zijn niet grappig. En die worden niet meegenomen in dit soort analyses. “Ja maar vervangen kost 20K”

Ja das leuk, maar niet vervangen geeft een extra implementatiepost van €2K per maand voor extra beveiliging, ga jij maar rekenen hoe snel je dat dan hebt terugverdiend.
In vrijwel iedere serieuze plant waar je gaat rondkijken stikt het van dit soort oplossingen. "Ja die computer moet blijven want daarop programmeren we die oude PLC's", "Die bedient die pomp-installatie die we gebruiken bij de maintenance-cycle iedere 5 jaar" en weet ik het wat voor oude zooi je tegenkomt. MS-DOS applicaties die 1 ding (heel goed) doen, etc etc.
Niemand die daadwerkelijk daar risico/impact en kosten assessment hebben gedaan voor dat soort spullen kan ik je vertellen.

Ik weet dat het gebeurt, maar dat zijn precies de systemen die je bedrijf ontzettend tegenhouden in van alles. “Maar het gaat goed” is echt letterlijk alleen doomscenario failure analysis, maar kosten door extra overhead, kennishuishouding, maintenance en tech debt neem je gewoon niet mee.

Het is gewoon niet slim. Ook al gaat het “wel goed”, heb je er nog steeds kosten aan.
Grappig hoe jij precies weet hoeveel geld al die bedrijven kunnen besparen, terwijl dit soort zaken dagelijkse kost is bij de grote plants.

Schijnbaar is er toch "iets" wat ze tegenhoudt om er zoveel werk van te maken als jij beschrijft. Dat zal vast grotendeels financieel zijn, gok ik zo...
Wat mij vooral triggert in jouw reactie is niet zozeer óf die legacy-opstellingen bestaan (dat ontken ik nergens), maar hoeer naar de risico’s en kosten gekeken wordt. Jij wijst terecht op survivorship bias aan mijn kant, ik zie vooral de niet zo "survivorship". Maar er zit aan de andere kant óók een flinke bias: “het draait al jaren zo, dus het zal wel goed zijn”.

Als je uitzoomt naar onderzoeken van o.a. security-clubs zoals Veritas, consultants en risicostudies van Mitre, Sans en Mckinsey, zie je een vrij consistent beeld: een enorm deel van de organisaties onderschat de impact van legacy-afhankelijkheden. Niet alleen een beetje, maar structureel. Er zijn surveys waar grofweg 40 - 60% van de bedrijven aangeeft dat ze hun risico’s achteraf gezien toch te rooskleurig hadden ingeschat, terwijl tegelijkertijd 60%+ zegt dat legacy-systemen inmiddels “merkbare tot ernstige negatieve impact” hebben op kosten, wendbaarheid of veiligheid. Dat zijn geen incidenten meer, dat is gewoon patroon. (zie onderaan voor bronnen)
Dat zal vast grotendeels financieel zijn, gok ik zo...
Ja, omdat dus niet het hele plaatje bekeken wordt.

En daar komt dan nog iets bij wat je in de praktijk bijna nooit scherp ziet: OpEx. Iedereen staart zich dood op CapEx, die 20, 30 of 40k die een nieuwe besturingskast, PLC of machine-interface kost. Maar de rekening van “gewoon laten draaien” betaalt zich uit in een hele reeks onzichtbare posten: extra beheeruren, uitzonderingsregels in je netwerkontwerp, aparte monitoring, maatwerk­koppelingen, dure consultants die wél nog weten hoe die oude zooi werkt, hogere risico-profielen bij verzekeraars, projecten die duurder en trager zijn “omdat die ene oude doos niet mee kan”. Als je dat netjes uitsplitst, kom je in de praktijk heel vaak uit op 20 - 40% hogere operationele kosten over de levensduur van zo’n systeem, en in industriële OT-omgevingen soms nog hoger.

Hier een voorbeeld van Stantec:
Many utilities don’t see the full cost of owning their operational technology systems. They often place their focus on the upfront capital cost.

A forward-thinking OT plan should include:
  • Lifecycle-aligned investment models. These plan for upgrades, training, and long-term support.
  • Open system architectures. This helps to avoid vendor lock-in and encourages integration.
  • Transparent, scalable pricing structures. These allow for flexible growth.
  • Built-in cybersecurity that’s aligned with evolving standards from the National Institute of Standards and Technology.
  • Operator training and simulation tools to support team readiness from day one.
Utilities like those in San Diego, San Francisco, and the Great Lakes Water Authority are already using this approach. We’ve helped them embed long-term planning into their OT strategy. And we’ve seen results like 20 times return on investment, lower lifecycle costs, and greater workforce resilience.
Dat is ook precies waarom ik zeg: een risico-analyse zonder impact-component en zonder deze verborgen kosten is eigenlijk geen echte analyse. “Het gaat al jaren goed” is geen datapunt, het is een gok die tot nu toe goed is uitgepakt. Het probleem is dat je nooit van tevoren weet of jíj degene bent bij wie het wel fout gaat. Maersk, NHS, VDL, allerlei waterbedrijven en energie-operators dachten tot op de dag van de klap óók dat hun segmentatie, firewalls en airgap-achtige constructies voldoende waren. Tot een vergeten verbinding, een laptop, een remote verbinding of een stukje supply chain-software alsnog de binnendeur openzette. En dan blijkt dat dat ene verouderde systeem, die “mummy in de hoek”, de ideale springplank is voor alles wat je níet wilt.

Dat betekent niet dat iedere oude PC met een DOS-tool meteen de fabriek opblaast. Natuurlijk niet. In “serieuze plants” barst het van de oude rommel die al jaren zonder zichtbare problemen draait. Maar dat is nou precies wat survivorship bias aan de andere kant is: je ziet de 100 installaties waar het goed gaat en vergeet die paar waar het catastrofaal misging en honderden miljoenen schade veroorzaakte, of de tientallen waar men inmiddels alsnog miljarden in versneld herstel, segmentatie en modernisering heeft moeten stoppen. En dan heb ik het nog niet eens over de minder zichtbare schade: projecten die je niet durft, integraties die je niet doet, kwaliteitsverbeteringen die blijven liggen omdat “dat oude spul het anders niet meer doet”.

Wat ik probeer duidelijk te maken is dit:

ik zeg niet “sloop morgen al je legacy”, ik zeg ook niet dat jij je werk niet goed doet in plants waar dit dagelijks voorkomt. Wat ik wél zeg: als je álle kosten (beheer, beveiliging, overhead, technische schuld, verzekeringen én het staart-risico van een grote klapper) eerlijk in één model stopt, dan is de uitkomst in héél veel gevallen helemaal niet meer zo vanzelfsprekend in het voordeel van “laten we het maar zo laten, want vervangen kost 20k”. Zeker niet als je die kosten over 10-15 jaar uitstrekt.

En dit is niet iets wat ik zelf even bedenk en uit mijn mouw schud, nee dit is gewoon wat de industrie ook gewoon roept:
Last month, I walked into a boardroom where the CFO was celebrating a “successful” IT budget reduction. They’d cut operational expenses by 8% year-over-year. What they hadn’t calculated was the $2.4 million in hidden costs their legacy systems were generating annually.

This isn’t speculation. After auditing digital infrastructure across pharmaceutical and healthcare enterprises, I’ve seen the same pattern repeatedly: organizations focus on visible IT expenses while hemorrhaging money through legacy system inefficiencies they can’t see.

The Accumulation Effect

These costs compound annually. A legacy system that costs $2.4 million in year one will cost $2.7 million in year two as technical debt accumulates. By year five, you’re looking at $3.6 million annually. I’ve seen organizations spend more maintaining legacy systems over three years than it would cost to completely modernize their entire digital infrastructure.
Daar komt dan nog bij dat je de lifecycle niet in eigen hand hebt. Of het nou WINS, een oud Windows-platform, een vendor-specifieke runtime of iets anders is: op een gegeven moment trekt iemand extern de stekker eruit. Dan kun je nog zo overtuigd zijn dat het airgapped en firewalled “veilig genoeg” is, maar als de leverancier écht stopt met support, tooling en compatibiliteit, ben je gewoon je strategische speelruimte kwijt. Je zit dan vast in een afhankelijkheid die je in eerdere jaren bewust in stand hebt gehouden, en de rekening valt altijd op het slechtst mogelijke moment.

niet “IT moet altijd winnen van het primaire proces”, maar wel:

als IT zó diep verstrengeld is met je primaire proces dat uitval je miljoenen kost, dan is IT geen bijzaak meer. Dan hoort een volwassen organisatie niet alleen naar de aanschafprijs van een nieuwe kast te kijken, maar ook naar de doorlopende kosten van oud spul én naar de impact als het misgaat. En ja, dan is het antwoord in een serieuze risico- én impactanalyse “meestal nee”: niet omdat ik dat vind als ICT’er, maar omdat de combinatie van verborgen OpEx en potentiële klap simpelweg te groot is om weg te wuiven met “het draait al jaren goed, dus waar maak je je druk om?”.
terwijl dit soort zaken dagelijkse kost is bij de grote plants.
Dat het de realiteit van operations is, betekent niet dat het ook allemaal prima is. Sterker nog, als het echt dagelijkse kost is, dan zit precies daar een money pit van heb ik jou daar.


Meer bronnen:

Bijna de helft van alle organisaties onderschat de risico's die ze lopen in de praktijk.
SANTA CLARA, Calif. – Oct. 17, 2023 – Veritas Technologies, the leader in secure multi-cloud data management, today released findings of new research that shows 45% of organizations may be miscalculating the severity of threats to their business. The study, Data Risk Management: The State of the Market—Cyber to Compliance, which polled 1,600 executives and IT practitioners across 13 global markets, provides insights into the most pressing risks, their impacts and how organizations plan to navigate them.

Despite risk factors like interest rates and inflation pressing hard on organizations, ransomware and multi-cloud complexity are also growing concerns for businesses of all kinds. However, when survey respondents were initially asked whether their organizations were currently at risk, almost half (48%) said no. But after being presented with a list of individual risk factors, respondents of all levels recognized the challenges facing their organizations with 97% then identifying a risk to their organizations.

Notably, 15% of those surveyed did not believe their organizations could survive another 12 months given the risks they currently face. There was a disconnect, however, between the C-suite and those working in the trenches of protecting their organizations’ data, which could point to a communications issue: 23% of senior executives predicted the demise of their organizations in the next year, compared to just 6% of analysts and technicians.
En dan heb je 62% van de organisaties die afhankelijk zijn van legacy:
62% of organizations still use legacy systems
43% say security vulnerabilities are a major concern
68% rely on their internal IT team for maintenance
50% say the biggest reason they haven’t upgraded is because “the current system still works.”
48% say performance improvements are their top modernization goal

When asked who maintains these legacy systems:

68% said their internal IT departments handle it
20% rely on legacy software specialists
7% outsource to external vendors
5% admitted no one maintains it regularly (which poses a serious risk)
En dan het eindresultaat
The cost of such reluctance can be staggering. According to CIO Dive, almost two-thirds of businesses spend more than $2 million simply maintaining these outdated systems. Perhaps more concerning, 60% of IT leaders said that their legacy systems are experiencing “moderate to severe negative impact due to technical debt, including outdated code.
Maar de veelvoud van systemen die geen enkel problemen opleveren en "meer dan legacy" zijn, hoor je niks van.
Er zijn niet zo'n veelvoud aan systemen "die geen enkel probleem opleveren" als jij denkt hoor.
Publicly available channels grossly underreport incidents; for example, almost all respondents indicated having at least one incident, with 90% having some level of impact on the process, yet only high-profile incidents such as Colonial make headlines.
Gaat dus veel vaker fout dan je nu schetst. niet alles hoeft direct een 100% faal te zijn ook.
Grappig hoe jij precies weet hoeveel geld al die bedrijven kunnen besparen
Tsja, precies zou ik het niet willen noemen, maar even 5 minuten googelen leert je voldoende om te zeggen dat het gemiddelde bedrijf gewoon risico's onderschat, OpEx niet meeneemt. Mckinsey, SANS, Gartner, ze zijn allemaal bronnen voor mij om te kunnen stellen dat het gewoon zo is. Betekent niet dat ik niet ook de realiteit zie, maar onze twee waarheden van realiteit en theorie bestaan gewoon naast elkaar.

Ja het is dagelijks kost, nee het is niet slim.
IT zou de bedrijfsprocessen moeten ondersteunen. Maar in de praktijk moeten bedrijfsprocessen worden aangepast aan veranderende IT eisen. Oude CapEx's (investeringen) worden daarmee waardeloos (denk maar aan je prima werkende telefoon die onbruikbaar wordt door steeds hogere software eisen) en vraagt ook weer nieuwe investeringen. De uitgaven groeien, terwijl de inkomsten dat niet doen, tenzij je de prijzen verhoogt. Conclusie: alles wordt sneller duurder. En dan hebben we het nog niet over de afvalberg gehad.
denk maar aan je prima werkende telefoon die onbruikbaar wordt door steeds hogere software eisen
Mijn "prima werkende smartphone" heb ik na 6 jaar eindelijk vervangen, omdat ie niet goed meer werkte.
Maar in de praktijk moeten bedrijfsprocessen worden aangepast aan veranderende IT eisen.
In de praktijk moeten bedrijfsprocessen worden aangepast aan veranderende IT mogelijkheden. Automatisering en ondersteuning betekent niet dat je je proces nooit onder de loep hoeft te nemen.

En oude CapEx is leuk, maar als het apparaat al is afgeschreven en je hebt geen potje voor een nieuwe op dat moment doe je het niet goed. Dat je dan nog een jaar of tig doorwerkt met het oude apparaat omdat het functioneel en compliancy technisch kan dat is prima (zie mijn 6 jaar oude smartphone), maar zodra je bedrijfscontinuïteit in gevaar kan komen moet je een knoop doorhakken. En na 25 jaar aan legacy wordt het tijd om te zorgen dat je een dergelijk probleem niet nog een keer gaat hebben doordat alles wéér als monolitische architectuur wordt opgeleverd.
Voor de prijs van zo'n machine kunnen ze ook een consultant inhuren die een jaar lang werkt aan een zelfgemaakt systeem dat nieuwe protocollen naar oude protocollen omzet zodat het apparaat nog tien jaar werkt. Je zou gek zijn als je zo'n ding zomaar vervangt omdat Microsoft Server het protocol niet ondersteunt.

Het is te achterlijk voor woorden dat we machines die 30-50 jaar mee gaan afhankelijk laten zijn van protocollen die misschien net 25 jaar ondersteund worden. De IT heeft duidelijk nog een lange weg te gaan, want nog steeds worden dat soort machines gemaakt.

Wat dat betreft komt onze industrie er maar makkelijk mee weg. Ineens doen we alsof het normaal is dat kritieke apparatuur minder lang meegaat dan een goedkope auto en zitten er nog vak-ICT'ers te roepen dat er niks anders op zit dan vervangen zodra er een keertje een stukje ondersteuning vervalt. Maar goed, dat komt grotendeels ook door fabrikanten die hun drivers en software gesloten houden waardoor je hun software niet kúnt onderhouden zoals je bij normale machines wel kan doen.

[Reactie gewijzigd door GertMenkel op 25 november 2025 12:07]

Voor de prijs van zo'n machine kunnen ze ook een consultant inhuren die een jaar lang werkt aan een zelfgemaakt systeem dat nieuwe protocollen naar oude protocollen omzet zodat het apparaat nog tien jaar werkt. Je zou gek zijn als je zo'n ding zomaar vervangt omdat Microsoft Server het protocol niet ondersteunt.
Dat vind ik ook, maar vaak vind men dat de moeite niet waard. Want dat kost "tienduizenden"

fkn peanuts in vergelijking met gehele continuïteit op het spel zetten.

Het probleem zit em niet in de IT, kant maar in leveranciers en business keuzes die gemaakt worden.
In zulke gevallen zou ik tegen die tijd proberen om in Linux een Samba server te installeren die als WINS server fungeert: Samba WINS
Ik kan er met mijn hoofd niet bij dat men een systeem inricht met het idee dat dat tot in de eeuwigheid kan blijven bestaan.
Hoe moet je dan een systeem inrichten? Ervanuit gaan dat alles volgende week anders kan zijn? Geen TCP over IP, geen DNS, geen X86, geen block-storage, geen in-order gedrag van je CPU etc. etc. Je moet op een gegeven moment dingen voor waar aannemen anders kom je geen strohalm vooruit.
Een systeem moet met de tijd mee evolueren. Je hoeft echt niet elk jaar de complete stack te gaan ombouwen naar iets anders. Maar eens in de zoveel tijd moet je wel die grote stap maken. Als je voor het onderhoud van je systeem mensen nodig hebt die al met pensioen zijn dan ben je 20 tot 30 jaar te laat met het ombouwen van je applicatie.
Indien een systeem effectief functioneert en jarenlange ontwikkeling heeft ondergaan met aanzienlijke financiële investeringen, dan betreft het een geheel andere situatie. Deze systemen beschikken over essentiële functionaliteiten die doorgaans geen downtime kunnen tolereren, zoals de betalingssystemen van Swift, Mastercard en Visa. Een langdurige storing van dergelijke systemen kan leiden tot ernstige problemen, waarbij bijna niemand in staat is om betalingen te verrichten, alle vluchten wereldwijd worden geannuleerd, en de beschikbaarheid van voedsel en medicatie ernstig wordt beperkt. Dit kan resulteren in een situatie van totale chaos en mogelijk zelfs oorlog. Het is daarom verre van eenvoudig om een overstap te maken.
Des te belangrijker is het dus om het systeem zo neer te zetten dat je het geleidelijk kan moderniseren zonder het compleet neer te hoeven halen. Ik mag toch hopen dat dergelijke betalingssystemen geen "single points of failure" hebben en zodanig zijn opgezet dat je delen kan moderniseren zonder downtime.
Systemen die zo belangrijk zijn worden onderhouden, deel van dat onderhoud kan nu zijn, je afhankelijkheid van WINS er uit te schrijven. je hebt nog iets van een 8 jaar om dat te doen.

je doemscenario is is geen excuus om niets te doen, in tegendeel het is de rede om net te handelen. WINS is iets uit het NT4 tijdperk, met Windows 2000 server is de overgang naar DNS ingezet...
Des te meer moet je deze essentiële systemen blijven doorontwikkelen en met de tijd laten meegaan. Je kan dit soort systemen prima zonder downtime aanpassen, daar zijn methodieken voor. De risicos die hiermee gepaard gaan zijn vergelijkbaar en waarschijnlijk minder erg dan de risicos van het door blijven ontwikkelen op een platform waar de security, kennis en flexibiliteit ver te zoeken is.

Denken dat banken of het swift netwerk nooit iets wijzigen aan hun core systemen is incorrect. Hoe denk je anders dat banken en swift overstappen op ISO 20022?
Moet dat? Als het systeem 1 functie heeft die nooit veranderd, waarom zou die dan zo nodog mee moeten? If it ain't broke, don't fix it.
Alleen... het moment dat je er geen plakband meer op kan plakken komt onvermijdelijk een keer. In feite is het uitstel van executie waarbij de executie alleen maar pijnlijker wordt.

[Reactie gewijzigd door Sfynx op 25 november 2025 02:31]

Omdat als het wel "broke" gaat je dan dus bijna mensen op moet gaan graven om het weer "unbroke" te maken.
Ofwel je gaat er van uit dan het om een blackbox gaat, niemand mag eraan komen. Dat is toch een enorm risico voor een bedrijf? Dat is wachten op een ramp. Het kan jarenlang goed gaan.... Je bespaart enorm veel geld. Maar als het fout gaat dan ben je de klos en moet je in één keer net zoveel of meer geld uitgeven dan als je het wel netjes had gedaan. Korte termijn denken.

[Reactie gewijzigd door david-v op 25 november 2025 11:35]

Ja klopt precies. Vooral bij serieuze legacy systemen komt het voor dat er ook nog maar een handjevol mensen zijn die er mee weten om te gaan. Bij banken was dat echt een probleem aan het begin van deze eeuw.
in 2038 krijgen we weer een "wakeup" call als het epoch probleem om de hoek komt kijken. Ik verwacht vooral problemen bij embedded systemen die op de een of andere manier met timers of datums werken, al zal hier en daar de nodige business (kritische) applicatie wel omvallen door dit legacy probleem.
Dat gebeurd alleen bij volledig geïsoleerde systemen die nergens van afhankelijk zijn en met geen andere systemen verbinding maken, ofwel geen netwerk verbinding hebben. Dat soort systemen komen nauwelijks voor, embedded systemen vooral. Eventuele bugs kan je op een duur ook niet meer oplossen.
Er vanuit gaan dat alles volgende week anders is, is hier niet echt aan de orde. We hebben het hier niet over vorige week, maar over begin 2000 dat WINS niet meer relevant was.

Schrijf dit soort ‘bedrijfskritische systemen’ in 20 jaar af en bouw dan iets nieuws op. Als het echt zo kritisch is allemaal, dan hoort daar ook voldoende budget voor gereserveerd te worden.

Alle begrip voor stabiliteit in je bedrijfsvoering, maar stilstand is achteruitgang.
Het zou wat zijn als we met z'n allen stil blijven staan bij technologie "van toen". Waarom moderne server tech gebruiken als we VAX/VMS hebben .. En 32 bit OS is prima toch? Heeft altijd goed gewerkt dus waarom zouden we over moeten op 64 bit versies..
Waar ik op reageerde was: "Ik kan er met mijn hoofd niet bij dat men een systeem inricht met het idee dat dat tot in de eeuwigheid kan blijven bestaan." en toch doen we dat de hele tijd: als we een keuze maken doen we dat met het idee dat het een fundament is waarop we doorbouwenn. Dat neemt niet weg dat we moeten accepteren dat zaken anders kunnen worden, maar je kunt je software niet bouwen zonder door te bouwen op een basis die er al ligt. Je kunt niet alles tot in de eeuwigheid wegabstraheren en maakt dus keuzes. Zaken waarvan je weet dat ze minder vast zijn zul je achter een abstractielaag zetten om makkelijk te kunnen refactoren. Zaken die zekerder lijken ga je op doorbouwen. Je gaat ook niet de hele win32 API achter een eigen API zetten omdat MS kan besluiten bepaalde functies op te heffen.
Het heeft niets te maken met abstraheren eigenlijk. Het komt vrijwel nooit voor (behalve embedded systemen) dat je jarenlang (10, 20 jaar of langer) op een bepaalde basis kan blijven bouwen. Er is geen enkele OS (nogmaals weer de uitzondering voor embedded systemen) die niet wijzigt in de loop der jaren. Blijven hangen op API's of onderdelen die vervangen worden door anderen is al een alarm signaal.

Het probleem zit denk ik ook in het feit dat ontwikkelteams vrijwel altijd moeten vechten om dit soort refactor of vernieuwingsrondes te doen. Het levert de business op de korte termijn niks op, het kost alleen maar geld en gaat ten koste van nieuwe functionaliteit. Korte termijn denken. Dat zie je in vrijwel elke organisatie.
Dat ben ik volledig niet met je eens: OS'en zijn notoir in het supporten van oude oplossingen. Windows support nog steeds de volledige Win32 API (win16 API werkt ook nog op 32 bits Windows en MS adviseert om via virtualisatie oudere software op 64 bits OSen te draaien). Unix roots met Libc gaan terug tot 1970. Sure: als je OpenGL wilt of DirectX12 voor raytracing in wilt zetten lukt dat niet met de oude APIs. Maar niet alles heeft dat nodig.

Dat er structureel te weinig geld wordt gereserveerd voor moderniseren is zeker waar, maar om maar te zeggen dat je moet upgraden omdat iets 'te oud zou zijn' is ook raar.
maar om maar te zeggen dat je moet upgraden omdat iets 'te oud zou zijn' is ook raar.
Te oud bestempel ik iets als:
  • Er geen ondersteuning meer is vanuit de fabrikant/ontwikkelaar
  • Er geen kennis meer voorhanden is om het systeem te onderhouden/aan te passen
  • API's als deprecated worden aangemerkt
  • De gebruikte technologieën niet meer voldoen aan de huidige security standaards
  • Oplossingen/hacks worden bedacht om het core systeem niet aan te raken, want hoog risico of zie alle bovenstaande punten
Dus ja, als iets oud is volgens deze definitie (en ik vergeet vast wel een paar punten) dan moet je upgraden. Niks doen is je kop in het zand steken en hopen dat het goed blijft gaan.
Analoge machines werken, mits goed onderhouden, na honderd jaar toch ook nog?

Een van de redenen dat mijn oude Mercedes uit 1983 nog steeds rijdt, is dat die niet ge-brickt wordt door software updates die steeds meer hardware nodig hebben, of niet meer werken op die 'verouderde' machine. Van mijn Subaru uit 2022 is het een illusie om te denken dat die de 40 jaar haalt. Mechanisch wellicht wel, maar veel software zal na een bepaalde tijd niet meer worden 'onderhouden'. Als standaarden dan wijzigen en de auto niet wordt ge-update gaan er functies uitvallen.
Dit zijn geïsoleerde systemen (embedded), niet ergens mee verbonden zijn en niet afhankelijk zijn van externe factoren of connecties. Het enige probleem wat je hier kan tegenkomen is dat de hardware stukgaat en de nieuwe hardware anders aangestuurd moet worden (andere software). Dan heb je wel een uitdaging.
Mechanisch wellicht wel
Nou.... Je zei Subaru toch? :X
En nog een veel groter fortuin kosten als ze slachtoffer zijn van ramsonware. Ik heb dit best vaak meegemaakt. Cruciaal systeem, bedrijfskritisch, al tientallen jaren draait het en er wordt nauwelijks geld aan uitgeven behalve hier en daar wat fixen om het in stand te houden. Vernieuwen? Nee, niet nodig. Het werkt toch?

Ik moest ergens in 2020 een connectie tussen een Windows 2000 server! en een database aanpassen omdat de connectie echt te onveilig was en de beveiligde netwerkverbinding niet meer voldeed aan de huidige standards. Of we iets konden aanpassen aan de Windows 2000 server om alsnog die beveiligde verbinding voor elkaar te krijgen. Oh ja, het moest echt zo goedkoop mogelijk gedaan worden. Patchen en doorgaan.....

Je zou denken, dat is vast een klein bedrijf... Mkb....

Nope, moederbedrijf maakt meer dan 150 miljard euro omzet per jaar wereldwijd.

Ik geloof meteen dat er tientallen bedrijven zijn die hier nog van afhankelijk van zijn voor hun bedrijfskritische processen. Niet omdat ze niet anders kunnen, maar omdat ze simpelweg geld hebben bespaard jarenlang door het oude systeem niet te vernieuwen. Best triest als je het mij vraagt

Ik heb overigens de opdracht van die Windows 2000 server geweigerd. Aan dat soort gepruts wil ik niet meewerken.

[Reactie gewijzigd door david-v op 24 november 2025 23:26]

Die gaan ze pas aanpassen nadat ze gehacked zijn. Dan ineens is er wel urgentie. Zo gaat het altijd.
Dat zijn vaak zulke legacy hoeken in de omgeving waar niemand aan mag komen, want bedrijfskritiek process. En wat zeker niet aan het "moderne" interne stuk van het netwerk mag hangen, want geen enkele beveiliging.

Je zal verbaasd zijn welke legacy zut nog op WINS draait (of de client die NetBIOS gebruikt).

Onlangs tegen een miepende developer aangelopen die klaagde dat zijn Excel kritische formulieren niet meer werken als men vanuit huis werkt. Blijkt dat hij zocht op het internet en in een blog van 2020 wat handige dingen had gevonden. Die dingen dateren nog van het Windows NT tijdperk (de WinNT provider WinNT User Object - Win32 apps | Microsoft Learn ) en Excel van nu ondersteund die zoekopdrachten nog vanwege backwards compatibiliteit. En AD doet dat ook nog steeds voor backwards compatibiliteit. Dat werkt intern op je Windows client nog steeds op basis van NetBios in een van de opzoek stappen. Rara wat IT security recentelijk heeft verbannen van de VPN oplossing. Ja, je raad het al, WINS :D
ik zie in de link "win32 apps" staan. Dan moeten toch alle alarmbellen toch al afgaan? Werken win32 apps nog?
Win32 apps werken nog steeds, en doen dat in 2050 ook nog. Dat is de absolute kern-API van Windows.
ik heb in een fabriek gewerkt waarin een plc werd aangestuurd door een standalone NT4 machine.
Deze kon vervangen worden, echter moest dan de hardware en software ook vervangen worden.
Dat kostte 500.000

Dan zegt de directie, kijk maar op ebay voor reserve onderdelen mocht de boel kapot gaan,

Op zulke plekken ligt IT vaak heel ver achter. Software wat al 20 jaar oud is, hardware is 20 jaar oud.
Vervanging kost teveel geld en bedrijven nemen het risico.
Vervanging kost teveel geld en bedrijven nemen het risico.
En dat is de kern van het hele verhaal. De vraag is, wat gebeurd er als de NT4 machine niet meer te repareren is. Fabrieken waarvan de productie lijn stil valt, ik denk dat je dan te maken hebt met een meervoud van die 500k wat het kostte om dit risico te mitigeren.

Maar zoals je zegt, sommige bedrijven nemen dit risico, beetje gokken en op de blaren zitten als het mis gaat.
Dat is precies wat we 100x hebben aangegeven maar geen gehoor aan werd gegeven dat we niet kunnen blijven repareren.


Na vele jaren is het wel vervangen maar dat was heel lang na de levensduur
Als ze nog NT4 draaien maakt het ook niet uiit of Microsoft nog WINS support.
Ik vraag mij echt af of er mensen zijn die Server 2025 installeren icm wins.

Er zullen vast bedrijven zijn die nog nt4,server 2000 etc draaien maar die draaien toch al unsupported.
Alle hospitalen en overheden draaien nog steeds NT4 en Windows 2000 machines vandaag. "Nieuwe" machines met OpenVMS worden nog steeds verkocht, Itanium wordt nog steeds verkocht, er zijn volledige bedrijven die 486 en Pentium-clones verkopen. En je ziet echt wel gekke combinaties, in de MRI hardware zie je het equivalent van een Pentium 3 chip met Linux 2.6 een gloednieuwe FPGA aansturen (Siemens). Of in GE zie je een SunOS 8 met SPARC chips als een benodigdheid om software te compileren, en ja, Oracle verkoopt de SPARC reeks nog steeds, dus de hardware is meestal geen probleem, maar Solaris is niet veel veranderd sinds de Sun dagen.

IBM verkoopt COBOL runtimes op hun "cloud" dus je jaren 70 mainframe kan geconverteerd worden met EBCDIC ondersteuning naar "hun" Linux cloud en de volledige mainframe, alle applicaties draaien in een container.

Zolang de 'vraag' bestaat zal iemand dit verkopen. En de vraag is nooit, hoe gaan we dit moderniseren of veilig doen, de vraag is hoe gaan we van de oude machine naar een nieuwe machine zonder teveel veranderingen te doen, en dat mag dan best wat kosten, het is meestal toch de belastingsbetaler die zulke implementaties betaalt.

[Reactie gewijzigd door Guru Evi op 25 november 2025 17:32]

Maar allemaal unsupported door Microsoft.
Oftewel die hebben niets aan het feit dat Microsoft nu wins nogsteeds support in windows server 2025.
Wel zeker, want NT4 en Windows 2000 draaien ook nog steeds als de client machines voor veel van die hardware. De ondersteuning komt maar deels van Microsoft, officieel niet, maar met Microsoft Advantage en een groot genoeg contract krijg je meer flexibiliteit, maar 3rd party support bestaat wel degelijk, je kunt de Windows Update servers niet meer bereiken, wel, betaal een bedrijf een paar duizend euro en ze draaien de "Microsoft Update" voor Windows XP met SSLv3 support.

Hoeveel van die handheld devices draaien geen Windows CE - nog steeds ondersteuning vandaag, al die meuk is jaren geleden opgezet en hebben 'vandaag' WINS nodig, je gooit zulke dingen niet weg. Als Windows 2025 support vergaat in 2034 ga je wel bedrijven zien die de Samba implementatie verkopen als vervanging.

Ik heb vandaag nog steeds floppy's en Ultra320 schijven in mijn kantoor want af en toe heeft er iemand een nodig.

[Reactie gewijzigd door Guru Evi op 25 november 2025 17:41]

DNS bestaat al sinds de jaren 80, ver voor Windows nog een server OS had. Hadden bedrijven/Microsoft zich gestandardiseerd op DNS zou dit vandaag geen probleem zijn.

WINS is proprietary en de bedoeling was om NetBIOS op TCP/IP te laten werken. NetBIOS kwam van IBM om op hun Token Ring auto-discovery te doen. NetBIOS was al sinds de jaren 80 door IBM gestandardiseerd om in TCP/IP te werken, maar dan zouden Windows machines compatible geweest zijn met Unix en andere OS van die tijd, dat wou Microsoft niet.

En dit is nu juist het probleem met het Microsoft OS, designbeslissingen die bijna halve eeuw oud zijn worden nog steeds geimplementeerd (OLE/DDE) met alle haken die er vroeger aan hingen, namelijk dat computers nooit met elkaar buiten een gebouw zouden communiceren, dat iedereen op een netwerk zich goed ging gedragen etc.
Afgaande op het verleden krijg je dan nog de optie voor 3 jaar verlenging in de vorm van betaalde ESU, op Azure hosted zelfs 4 jaar ESU. Dus als je echt nog stevig WINS verslaafd bent en je zet gerust even een Azure VM op daarvoor, ofwel, een paar jaar extra mag zo'n bedrijf wat kosten, dan stopt WINS "pas" over 13 (!!) jaar echt volledig ermee
...
(Microsoft first-party supported te zijn, wie weet hoe lang AV suites nog durven Windows Server 2025 semi-veilig te laten voelen richting bepaalde types zelfs na die datum }> )
toen toch vaak toegevoegd om de performance op te krikken met printen en bepaalde netwerk zaken ondanks alle praatjes van MS toch onmisbaar
Ik durf te wedden dat er alsnog over 9 jaar gezeik is. "Ja maar het is mijn keus!"
En dat betalen de bedrijven dan nog voor 8 jaar tot Microsoft geen specialisten meer kan vinden om support te bieden...
Ah de S als dollar teken om aan te geven dat het een bedrijf is dat geld wil verdienen! Is funny cause is true!
En dit zijn mensen die het altijd neerbuigend hebben over Microsoft en Apple, terwijl ze groot fan zijn van Android, gemaakt door het grootste advertentiebedrijf ter wereld om hun ijzeren grip op het internet te verharden en hun echte klanten de data van hun fans te kunnen verkopen.
WINS was back in de Lanparty dagen toch echt wel een must have. Windows stations zaten nog in een zg. NETBIOS master browser systeem, dat ieder station zichzelf adverteerde met broadcasts en anderen daar weer via een broadcast op reageert. Met 50+ clients op hetzelfde subnet begon die broadcast serieus vervelend te worden.
WINS voorkomt dit.

Windows clients melden zichzelf nu bij een WINS server, die ze ook weer kunnen raadplegen voor NETBIOS aanvragen.
Ze hoeven dus niet meer te broadcasten.
Een enorme boost op je netwerk als je veel Windows clients had.
Win je er ook wat mee? Dat je betrouwbaarder anderen kan vinden?

Ik vond dat het altijd zo lang duurde voordat je 'network neighborhood' zich vulde.
Met WINS werdt inderdaad je network neighborhood nagenoeg instant, maar daarnaast zag je ook stations buiten je eigen IP subnet. (omdat je geen broadcasts hoort te krijgen uit andere nettten)
In NT 4.0 was Wins al een draak. Zodra je de boel op dynamisch zette, wat eigenlijk de preferred methode was, kreeg je na verloop van tijd errors omdat servers niet meer geresolved werden. Sinds Windows 2000 is DNS dé methode voor name-resolution.

Knap dat Microsoft iets was al sinds 2000 niet meer nodig was nog zo lang doorondersteund heeft. Mocht je in 2034 nog applicaties hebben die Wins nodig hebben, dan sta je dan dus al 35 jaar stil.
In geval van nood kan je vast nog overstappen op samba-server voor je WINS resolutie.
Samba is open source. Dat kun je zelf blijven onderhouden zo lang als je het maar nodig vindt, en er zit een prima werkende WINS-implementatie in. De oudere versies die alleen een NT4-domein bieden, kunnen daar functioneel prima mee overweg.
Als je in 2034 nog met NT4 te maken hebt, verwacht ik dat een oude Windows Server 2025 blijven draaien de makkelijkste optie is.

Samba draaien kan natuurlijk nu ook al maar voor de security hoef je het niet te doen als je netwerkbeveiliging nog op NT4 is blijven hangen.
WINS is een NT4-erfenis. Als je daar inderdaad nu nog mee zit, ben je qua LCM knap hopeloos. Als je dan nog iets wilt draaien dat supported is, is Samba je beste optie. Mogelijk krijg je die, dus mét WINS, nog van een partij als RedHat tegen die tijd.. al zou het mij niet verbazen dat het ook daar gewoon een keer stopt.
Dat zal eerder 2044 worden, want in 2033 zullen er nog genoeg mensen zijn die niet willen overstappen :)

Wel mooi dat ze dit nu al aankondigen
Wat het uiteindelijk daadwerkelijk zal worden, zal de tijd leren inderdaad. Microsoft heeft ook diens les(sen) wel geleerd met NT4. Wellicht dat men (mede om een dergelijke gedoe te voorkomen) daarom nu en ruim van te voren dit al aangeeft.
Ondersteuning tot 2034, heb dit echt nooit ergens in gebruik gezien. Verbaast mij eigenlijk ook dat het (blijkbaar) pas 3 jaar geleden deprecated heeft gekregen.
heb dit echt nooit ergens in gebruik gezien.
Dan kom je waarschijnlijk op omgevingen waar ik de domeinmigratie of DC-upgrade heb gedaan. 😋

Maar serieus: zoveel omgevingen geweest in het verleden waar WINS nog draaide omdat WINS nog draaide, m.a.w.: omdat niemand het ooit uit heeft durven zetten. In het kader van ‘vaak ben je te bang’ nam ik het uitschakelen altijd mee als bijvangst bij een dergelijke migratie, met natuurlijk een fallback naar alsnog inschakelen als het strikt noodzakelijk was.

Dat punt is in geen enkel geval gekomen, al zijn er wel (zeldzame) momenten geweest waar bij hele specifieke situaties alsnog voor specifieke devices een handmatig ingrijpen nodig was.
of het (aloude) alternatief voor DNS en WINS, rotsvast op elk windows filesystem, en overrides DNS ;-)

notepad.exe %SystemRoot%\System32\drivers\etc\hosts
Lmhosts is voor netbios naan resolutie, hosts voor dns
WINS, dat heb ik echt al jaren niet meer gelezen. Kan me het volgens mij alleen nog maar herinneren volgens mij uit de begintijd van Windows 95 dat ik er voor het eerst mee in 'aanraking' kwam. Nooit gebruik van gemaakt voor zover ik me kan herinneren. Heb het zelf ook nergens gebruikt zien worden, maar blijkbaar zijn er toch plekken waar het wél wordt gebruikt.
Zelfs in 9x zit uitstekende ondersteuning voor DNS dus ook daar is WINS totaal overbodig :)

Om te kunnen reageren moet je ingelogd zijn