Dus deze "feature" veroorzaakt precies het probleem dat die had moeten helpen voorkomen. Zucht.

De reden voor STS is kennelijk dat er een kip-ei-probleem bestaat: om een SSL-certificaat (waarom heeft men het niet over TLS?) te controleren moet je de tijd weten; om de tijd op een betrouwbare manier te vinden heb je een SSL-verbinding nodig. Microsoft dacht dat op te lossen door het veld ServerUnixTime uit de SSL-handshake te gebruiken, aannemende dat die de correcte tijd zal meegeven. Toen Microsoft dit implementeerde zette OpenSSL daar al random waarden in omdat de tijdvelden kunnen worden misbruikt om clients te fingerprinten. Kennelijk ging Microsoft ervan uit dat ze alleen met Windows-servers rekening moesten houden.

Mijn eigen ervaringen met Microsoft zijn niet recent, ik heb denk ik sinds 2007 niets meer met hun platforms te maken gehad. Daarvoor had ik als ontwikkelaar met ze te maken. Ik had zelf een mainframe-achtergrond en het bedrijf waar ik voor werkte probeerde naar .NET te migreren (wat ze uiteindelijk niet gelukt is). De ervaring die ik met ze had was eigenlijk heel vergelijkbaar met hoe ik als privégebruiker de introductie van Windows95 meemaakte: de tamtam over hoe geweldig het allemaal was was oorverdovend, en de praktijk viel, vergeleken met die tamtam, vies tegen. Het oogde uitermate gelikt, maar het rammelde op schrikbarend veel plaatsen als je diep genoeg kennis maakte met de details. De browserondersteuning van ASP.NET bijvoorbeeld was niet gebaseerd op webstandaards (CSS, JavaScript) maar op het genereren van heel andere code die voor non-Microsoft-browsers echt rammelde. Er zaten constructies in die voor met name pagina's met een browse in database-records onder water zo godsgruwelijk veel extra code genereerden dat browsers veel te lang nodig hadden om ze te renderen. De SOAP-ondersteuning werkte ongeveer automatisch als je maar met een Microsoft-server praatte, maar als je moest communiceren met een mainframe bleken attributen uit de SOAP-standaard die Microsoft zelf niet gebruikte domweg niet ondersteund te worden (zoals range-definities voor numerieke velden, essentieel omdat mainframe-applicaties met decimale getaltypen werken).

Voor onze applicatieontwikkeling hadden we dingen nodig die Microsoft of Microsoft-partners pas over minimaal een jaar zouden leveren. Als je dan een volwassen oplossing suggereerde van buiten dat kliekje kreeg ik de indruk dat vanuit Microsoft (die betrokken was bij het conversieproject) achter de schermen meteen een campagne gestart werd om je vanuit allerlei hoeken te beïnvloeden om vooral niet nu iets te kiezen dat Microsoft zelf nu niet kon leveren, en daarbij volkomen te negeren dat je het wel nu nodig had.

Ik kreeg in die tijd ook de indruk dat Microsoft ontwikkelaars zo intensief bezig hield met vernieuwingen in het platform dat ze onvoldoende aandacht en energie overhielden voor de applicaties die ze moesten bouwen. Ik heb me afgevraagd of dat een bewuste strategie was om de kwaliteit van interne ontwikkelaars van bedrijven te saboteren zodat alles uitbesteden aantrekkelijker werd.

Er zit een heleboel bij waarvan ik nooit kan bewijzen dat het doelbewust zo gedaan werd, maar ik heb toen een heel nare smaak aan dat bedrijf overgehouden.

Inderdaad kiezen tussen 2 kwaden, voor 2016 kwam net regelmatig voor dat Windows systemen geen windows updates konden binnenhalen, omdat de klok meer dan 15 minuten gedrift was, laat staan langer, of systemen die geen battery-backed-up RTC hadden (of meer hadden omdat de knoopcel of penlites op waren...

Hiervoor hebben ze in mijn optiek de botte-bijl optie gekozen zodat een computer die op 1 januari 1979 staat in korte tijd naar 17 augustus kan vliegen. Een botte bijl die minder erg is dan de optie om elke 450 seconden 7 seconden bij te snoepen, dan staat je klok op 1979 naar nu over ongeveer 31 miljoen seconden per jaar, gedeeld door7/ 450 seconden, kom je ongeveer uit dat je klok weer goed staat nadat je PC 228 miljoen seconden aangestaan heeft...
Dan zijn je windows updates ook niet meer nodig, en zit je aan Windows 18, die je niet hebt, omdat de updates niet binnenkomen.

Ik heb het een en ander aan ervaring met NTP op Linux systemen. Het is gezond om bij het booten van een systeem (voordat belangrijke services gestart worden) de tijd te "steppen"; dat kan met ntpdate of met het 'iburst' keyword in ntp.conf.
Wanneer alle services draaien is ntpd in de meeste gevallen prima in staat om de systeemklok gradueel bij te regelen.

Compleet eens dat het "steppen" van de systeemtijd aan allerlei kanten problemen kan opleveren.

Het NTP protocol gaat er vanuit dat er een kundige systeembeheerder bij zit die de boel configureert, initialiseert, en monitort.
Dwz hij zorgt er voor dat de client binnen de maximale tijdsprong zit, start de boel op, controleert of de tijd goed gelocked is, en bidt dan dat het niet fout gaat.
Omdat bidden niet helpt heeft ie daarnaast een network monitoring system wat de clients monitort om te zien of er nog wel een lock is, alerts stuurt als dit niet het geval is, en als ie die alerts krijgt gaat ie weer inloggen op die client om te kijken wat er mis is, en eventueel bovenstaande te herhalen.

Je snapt wel dat dit in bepaalde omgevingen prima werkt, maar dat "de Windows computers van de wereld" (bij de mensen thuis enzo) er daar niet een van is. Standaard NTP gebruiken op zo'n systeem zal onvermijdelijk leiden tot ongesynchroniseerde klokken.
Ik snap best dat Microsoft waar een workaround voor probeert te verzinnen! En als er dan ook nog SSL in de picture komt dan wordt het allemaal nog moeilijker.

Ik zou zeggen, voor je hen zo neersabelt: kom met een betere oplossing. Liefst een die werkt zonder weer een hele nieuwe tijdserver infrastructuur op te moeten zetten.

Ik zou niet te veel aandacht meer aan windows besteden. Het is een samenraapsel van software bulten en het systeem is failliet door het kreupele windowsupdate en al die ransomware waardoor de ene na de andere wordt uitgefaseerd (versleuteld)

Daaraan toegevoegd : en wanneer het systeem blijft draaien , en de eigen frequentie bron stabiel is.
Steppen is meer nodig geworden met systemen die suspenden. - laptops bijvoorbeeld, maar ook VMs (zowel suspend als variabele cpu tijd/frequentie) .

Als je een gesuspend systeem weer wakker maakt wil je geen uren hoeven wachten totdat de versnelde klok weer 'bij' is .

systemd-timesyncd is een frequent draaiende sntp client bijvoorbeeld.

(sntp - simple ntp - pak de tijd en zet die erin, geen phase-locked-loop om een lokale oscillator stabiel te koppelen aan een erg stabiele remote tijdsbron )


Klopt , maar langdurig fors afwijken omdat de maximale bijregel-stap klein is, is ook een fors probleem.

En de wereld bestaat niet meer alleen maar uit systemen die altijd aan staan, en altijd met dezelfde klokfrequentie draaien, en dat is wel min of meer het platform dat klassiek NTP verwacht .

Vertel, wanneer is dit een probleem? Het gebeurt namelijk alleen met opstarten, en ik hoop voor je dat je dan niet al met transactionele zaken bezig bent. Als het servers betreft dien je de biosklok goed in te stellen, als het virtuele servers betreft dan is een en ander al geregeld. Dus je zoekt een probleem waar het niet is.

Ook ntpdate op Linux doet dezelfde grote stap….

Wil je secure ntp? Gebruik dan als een van de eersten ptp. Op NANOG was een interessante thread over hoe je veilig je tijd zet en bijhoudt. (Suggestie: Rb klok die gesynct wordt met GPS en als fallback NTP van primaire sources). Tijd is voor transactionele systemen een stuk lastiger om goed te doen dan alleen ntp. Reden: GPS kan makkelijk worden gestoord/misleid en NTP is nogal gevoelig voor DDoS en andere zaken.

Die grote tijdstap aan het begin is pas het begin om je klok binnen transactionele systemen op orde te krijgen.

ntpdate doet geen grote stap omdat de system time default elke 11 min wordt gekopieerd (rtcsync) naar de RTC. Zie man chrony.conf

Tenzij de batterij leeg is of dat de VM onder hyperv draait (recent nog meegemaakt)

En dat ook geen incompetente controlfreak de firewall beheert en alles behalve HTTP(S) dichtzet want "security risico" .


Het is vrij duidelijk een kludge, gebouwd op ongeveer het enige dat bijna zeker werkt zodra er uberhaupt iets van connectivity is.
En een hoop ITers die zelf erg goed zijn hebben de neiging om te zeggen "laat alles maar kapot zijn als je het niet netjes volgens het boekje doet met het daarvoor bedoelde protocol" .

In het Ars-Technica artikel zie ik nergens dat het probleem alleen tijdens opstarten zou optreden (alhoewel enorme stappen ook dan totaal onacceptabel zijn). Wat is jouw bron om dit te stellen?

Ik weet niet exact hoe het werkt, maar als de RTC (Real Time Clock, meestal voorzien van batterij zoals CR2032), tijdens opstarten, een datum en tijd aangeeft die eerder is dan de laatst gelogde tijd (in bijv. het register), dan weet je al dat de RTC niet klopt. Sprongen terug in de absolute tijd horen dus sowieso om een handmatige goedkeuring te vragen.

Ik kan me, ik meen van een Sun workstation, tijdens booten, een waarschuwing herinneren in de trant van
Dat is niet voor niets.

Voor de meeste mission-critical systemen (vooral servers, ik heb het niet over niet de oude game-PC van zoonlief) zijn sprongen in de tijd simpelweg onacceptabel. Waarbij je security-risico's zeker niet moet uitsluiten (denk maar aan replay-attacks met TOTP codes). Als zo'n tijdsprong extern te triggeren valt, zijn je zorgen niet beperkt tot DoS.

Offtopic: Het komt hier (grote dienstverlener) regelmatig voor dat onze Linux VM's regelmatig worden gepauzeerd (>1h) onder HyperV en dat is inderdaad zeer onacceptabel. Dat zal wel met storage te maken hebben.

Het migreren van Windows naar Linux en Unix was wel wat lastig (drivers randapparatuur), maar van de overstap heb ik nooit spijt gehad. Met Windows waren constant problemen, BSODs en beschadigde herstelpunten (vraag mij niet hoe dat kan), computervirussen die de ene ramp na de andere veroorzaakten. En nu dit gedoe met NTP. Ik vraag mij af hoe lang dit OS nog wordt uitgegeven.

Zo lang het oligopolie er geld aan verdient! Aan een gratis desktop die het altijd doet verdienen ze niks. Bij ons was de migratie eenvoudig. Windows only randaparatuur werd gewoon vervangen en windows only software webbased afgenomen met een wat migratiepad naar iets anders of niet als de leverancier mee werkt. Wij hebben Microsoft nog op bezoek gehad (een sniffer via een goldpartner) omdat ze niet geloofden dat we waren overgestapt naar LibreOffice.

In een perfecte wereld wel. In de echte wereld, waar bios batterijen of laptops op kunnen raken zal ook ntpdate de systeemklok gewoon hard deze eeuw intrekken. Dit hele verhaal is geneuzel om niets.

Niet helemaal geneuzel, kennelijk is er echt wel een issue, maar zoals TO aangeeft is ook een beetje overdreven. :-)

Een klein aantal beheerders zien dit probleem een levert ook echt issues, zoals SQL transacties die uitgevoerd worden en de tijd schiet 3 uur terug.. Dat is niet heel prettig en erg vervelend. Dus het is best een groot probleem maar het betreft maar een paar lui die dit melden, mogelijk hebben ze een speciale configuratie en dat hun dit gedrag zien, maar er is een workaround dus prima toch!

Verder moet ik even kwijt over de opmerking hoe schandalig MS bezig is hiermee, dat dit ook wel met een korreltje zout genomen kan worden. Vermoedelijk heeft MS tijdens de ontwikkeling een deel van de standaard implementatie niet goed opgenomen of fout begrepen of het staat gewoon onduidelijk beschreven in de standaard.. Zeer waarschijnlijk komen ze in de toekomst wel met een aanpassing van hun protocol en dat het wel juist de standaard volgt.

STS blind uitschakelen zonder dat je tegen deze bug aanloopt zou ik wel voorzichtig mee zijn.

Toekomst! Ze moeten nu de standaard volgen. Check de kerberos ellende in het verleden.

Het gaat hier niet om fouten in het toepassen van protocollen, het gaat om wat ze vervolgens met data uit zo'n protocol doen. Hier is een veld uit de SSL-handshake gebruikt alsof het een betrouwbare tijdbron is. Zo is dat veld helemaal niet bedoeld, en de informatie die het NTP-protocol levert om als client te kunnen bepalen hoe nauwkeurig het ontvangen tijdsignaal is ontbreekt in de SSL-handshake. De SSL-handshake is daardoor helemaal niet geschikt om als betrouwbare tijdbron te dienen.

Verder hebben hun huiswerk niet gedaan, want op het moment dat dit werd ingevoerd zette OpenSSL (geen kleintje) al een paar jaar random waarden in het gebruikte tijdveld om misbruik voor fingerprinting tegen te gaan. Dat suggereert dat ze niet verder dan hun eigen platform hebben gekeken.

Microsoft is een van de grootste softwareleveranciers ter wereld en je mag van ze verwachten dat ze degelijk en professioneel werk leveren, inclusief het beoordelen van oplossingen van hun ontwikkelaars door ervaren, kritische en nuchtere collega's die niet zo gefocust zijn op dat ene probleem dat ze zich er teveel door laten meeslepen. Microsoft heeft zelf vaak genoeg luidkeels uitgedragen dat het de allerbeste ontwikkelaars heeft. Pure marketing, natuurlijk, maar wie doelbewust hoge verwachtingen wekt legt zelf de lat daarmee hoog voor de eigen beoordeling. En dan mag je dit rustig getruukt broddelwerk noemen.

Wij van WC-eend dus,

luntrus

Even naar wat RFC's gekeken voor SSL en TLS. Beide protocollen bevatten in de "client hello" en "server hello" een random-veld. Bij TLS 3.0 zijn dat 32 bytes random data, bij SSL 3.0 en TLS 1.2 zitten daar 4 bytes voor een Unix-timestamp in (seconden sinds 1-1-1970) en 28 bytes random data.

De RFCs voor SSL 3.0 (uit 2011, dus zo'n vijf jaar ouder dan STS) en TLS 1.2 (2008) geven expliciet aan dat die tijd niet correct hoeft te zijn voor het basisprotocol, wat het een slechte bron voor de tijd maakt.

STS zou dus incompatibel moeten zijn met TLS 1.3. Je zou zeggen dat het allang afgezonken had moeten worden. Gaat het misschien mis omdat Microsoft over het hoofd heeft gezien dat er iets actief is dat niet meer werkt?

SSL 3.0: https://www.rfc-editor.org/rfc/rfc6101
TLS 1.2: https://www.rfc-editor.org/rfc/rfc5246
TLS 1.3: https://www.rfc-editor.org/rfc/rfc8446

Oeps. Daar had TLS 1.3 moeten staan.

exact: Microsoft Windows is eigenlijk al jaren totaal passé!

Bijzonder dat andere dit eigenlijk nooit ervaren, behalve de gene die overstappen.

Ik kan mij de laatste BSOD niet meer herinneren, beschadigde herstelpunten, nooit last van gehad.
Computer virussen?

Klink voornamelijk als een slechte inrichting.

Laat eigenlijk zien, hoe weinig sommige eigenlijk echt met Windows werken.

Klinkt als een slechte inrichting of slechte afspraken.

\
Terwijl het bij alle grote bedrijven nog steeds gebruikt wordt.
Net zoals de meeste ransomware aanvallen voornamelijk konden gebeuren door slechte keuzes tijdens de inrichting, ondanks de adviezen om het anders te doen.

Ik zie aardig wat wensdenken. Maar MS is natuurlijk niet passé. Ja andere OS'sen hebben bepaalde zaken beter voor elkaar, realiteit blijft dat MS binnen bedrijven nog de hoofdmoot is. (W32time) time.windows.net is niet heilig, maar voldoet over het algemeen wel. NTP binnen het netwerk, altijd handig. Soms is een paar miliseconden genoeg voor vreemde foutmeldingen.

Er zijn nog wat hardnekkige brandhaarden omdat er nog steeds veel mee wordt verdiend (hackers en oligopolie)

Mag je jokken? Iedereen heeft last BSOD's en mislukte updates en dus ook ransomware. Je klinkt als leverancier van fossiele brandstoffen die aan het greenwashen is. Je weet het al jaren maar verdiend er als oligopolie flink aan en geeft de beheerder altijd de schuld. Ook zo iets typisch. Als de beheerder het probleem is zou dat ook een fors probleem moeten zijn in de UNIX wereld maar dat is het niet. Kijk ook naar Google zelf. Miljoenen Linux servers en windows is daar verboden ivm security en ransomware.

De hoofdmoot zit alleen in administrative afdelingen. Bij de rest is het al uitgefaseerd. In Amerika. De desktop market share is daar zelfs al gezakt naar 59% https://gs.statcounter.com/os-market-share/desktop/united-states-of-america Zelfs een desktop device op basis van een Linux kernel is daar al bijna 10% Microsoft zelf wilt dat alles naar de Azure gaat en dat is ook al bijna allemaal Linux. MS heeft daarvoor zelfs een eigen Linux distro voor: https://www.techradar.com/news/microsoft-reveals-azure-linux-is-available-now

Ja dat zeg ik! (toch? bijna niemand meer; in mijn professionele kring zelfs geeneen)

Dat is precies de makke van zoveel technerds : hun eigen bubbel voor 'representatief' aannemen en van daaruit allerlei algemene uitspraken doen en verwachtingen uitspreken.

Hier ook geen een en toeleverancier ook niet. Niks eigen bubbel. Heel verstandige keuze gezien alle ransomware en ook nog eens een besparing van 90% op ICT incl operationele kosten.

Toch bijzonder dat we dit bij onze bedrijven nog nooit tegengekomen zijn op grote schaal. Maar tja... Ik werk ook maar voor een groot internationaal IT bedrijf en kleine MKB klanten.

En het zijn zelden de beheerders dit de oorzaak zijn maar degene die het beleid voeren. Als wij security hardening toepassen, en gebruikers kunnen daarna met hun legacy applicaties niet meer werken, die denk je dat het argument dan wint?

Leuk als je ook een Unix, wat vaak dedicated backend systemen zijn, vergelijkt met een desktop, waarop gebruikers met diverse vage applicaties allemaal moeten werken, die regelmatig geupdate moeten worden.

Ook een leuk voorbeeld... Google, een zwaar IT bedrijf, niet het typische MKB/Enterprise bedrijf.

Je begrijpt dat je voorbeelden precies het probleem laten zien van je argumenten die je gebruikt?

Azure is helemaal niet bijna alles Linux. En wat is er vreemd aan, dat MS daarvoor zijn eigen Linux distro heeft?

je eigen bubbel inderdaad. Afgezien een vorige klant, waarop men 15 jaar oude CAD tekensoftware gebruikte, ken ik niemand die op Linux werkt. En daar is men nu ook gewoon over op een Windows applicatie voor de legacy tekeningen, de rest gaat gewoon in SolidWorks... Wat alleen op Windows werkt.

Correct statement. Dit zie je vaker bij dit soort claims, maar ze hebben eigenlijk geen idee, waarover ze het nu precies hebben. Ze baseren alles op hun eigen ervaringen, in hun eigen belevingswereld.


Ik ken en heb echt geen enkele leverancier die op Linux werkt op de desktop. Eigenlijk ook geen bedrijf. Sommige gebruiken wel apple, maar lopen vaak tegen compatibiliteits problemen aan.

Besparingen van 90%, dat maakt je claim eigenlijk direct onwaar, want dit is helemaal niet realistisch voor bedrijven.

Twee regels en nog snapt ie het niet .

Prima dat je een eigen (en verstandige) keuze maakt .
Alleen jouw omgeving als representatief beschouwen voor 'wat de wereld doet' is een kleine bubbel .

Het is alleen de redenering "niemand gebruikt het WANT ik en om mij heen zie ik het niet meer" die gewoon oogkleppen laat zien .
Microsoft heeft nog steeds tussen 60-70% marktaandeel op desktop/laptops .
(De rest is OS X , en een fractie Chrome OS )

Ik kom bij aardig wat bedrijven binnen en afgezien van wat 1-4 pittertjes inderdaad weinig Linux als desktop. Andere alternatief kom je dan vaker tegen en dat is Apple. Is het mogelijk? Zeker maar vaak zie je het dan gecombineerd met browser-applicaties op servers. Waar dus MS echt niet hoeft.

Ik zie nog zeker wel 10 jaar windows desktop/servers gewoon blijven bestaan.

En mijn ervaring is dat vaak dan ook, Citrix / Azure Virtual Desktop / Windows 365 gebruikt wordt voor dat soort devices.

Je bent je eigen belevingswereld aan het projecteren. Je oligopolie bubble mag niet uit elkaar spatten.
Grote techbedrijven als Twitter IBM Google Booking en Facebook gebruiken intern allemaal Ansible/Kubernetes/Docker/Linux en de programmeertalen Golang/Python/perl Bij sommigen zoals nu.nl is ook django/python/LInux de basis.

Bij Google is zelfs een windows desktop verboden na een security incident in Azië. Je moet een hele goeie reden hebben om toch met windows te kunnen werken. Daar draaien ze (naast een paar miljoen Linux servers) een gLinux desktop (debian gebaseerd). Meer dan 100.000 devices: https://cloud.google.com/blog/topics/developers-practitioners/how-google-got-to-rolling-linux-releases-for-desktops
Wij zelf gebruiken ook allemaal Linux devices (xfce) en gebruiken https://theforeman.org voor het patchen. Samen met Libreoffice en de open source ontwikkeltools kost het allemaal niks. Besparingen denk ik wel meer dan 90% (aan software licenties ,personnel, hardware en minder incidenten)

Wat frappant is, dat je niet zegt O klinkt interessant vertel eens hoe dan? Je ziet het blijkbaar als een bedreiging van je eigen business. Je staat namelijk niet open voor een goedkope ransom vrij en onderhoudsarm alternatief! Zegt genoeg over jouw bubble. Dat alle top 500 super computers Linux draaien weet iedereen maar er zijn ook veel grote bedrijven: https://www.tutorialspoint.com/25-big-companies-and-devices-running-on-gnu-linux Van het grootste software bedrijf ter wereld (IBM) is bekend dat de meeste medewerkers kiezen voor een Mac of Linux desktop. Het bedrijf is daar blij mee omdat o.a. de helpdesk veel minder belast is geworden. Ik ken persoonlijk gemeentes die absoluut niet tevreden zijn met een windows desktop ivm de vele incidenten zoals de bekende: [url https://www.security.nl/posting/712153/Kamervragen+over+paspoortproblemen+in+Almere+door+uitvallende+printers [/url]

Absoluut niet, mede omdat dit voor bijna geen enkel bedrijf haalbaar is, en als dat nodig is, doe ik gewoon Linux of MacOS beheer en implementaties. Ben al steeds meer bezig met Apple, dus daar maak ik mij niet zo druk om. De sales tunnel bevat trouwens geen enkele Linux Desktop aanvraag.

Nee hoor. Maar ik weet dat de aanschaf maar een heel klein deel van de TOC is. Onderhoudsarm klinkt leuk als sales pitch, totdat je verder gaat kijken hoe je de applicaties allemaal niet gaan beheren en er eigenlijk weinig alternatieven zijn die bieden wat de meeste bedrijven nodig hebben.
Ik ken nog maar weinig alternatieven voor AzureAD, Intune voor software/applicatie distributie/MDM inclusief MFA, SSO en SIEM.

Of over jouw bubble waarin je zit?

Wil je nu specifieke servers (HPC) vergelijken met Windows Desktops aka Kantoor automatisering? Seriously?

Als je we top 25 lijst eens bekijken, dan hebben we het of over Linux bedrijven, zware IT bedrijven, waarbij sommige over Servers en appliances. Niet de standaard Desktops dus. compleet verschillende werelden. Is alsof je een fiat 500 vergelijkt met een vrachtauto.

We hebben hier ook de nodige Linux,Unix, servers draaien, grote databases, web server, applicatie servers. De applicaties op die servers hebben trouwens ook de meeste storingen.

[2 jaar oude post, waarin MS inderdaad het nodige had met printer problemen. Was dat niet Printer Nightmare in die periode?
Waardoor je dus als beheerder gewoon de printerdriver distributie goed moest regelen?
Hebben we hier trouwens ook last van gehad. Printer driver package maken, en dit naar de desktops distribueren was de oplossing.

Lees trouwens nergens dat Almere er echt problemen mee had. Technisch gezien is printerdrivers laten downloaden vanaf de print server gemakkelijk, maar heeft altijd ook nadelen gehad.
Was bij ons trouwens 2-5 dagen werk om alle printerdrivers te distribueren naar de werkstations en verschillende omgevingen.

Maar ik ken persoonlijk ook personen die absoluut niet tevreden zijn over Apple of de Linux servers.
Dus zegt niet zoveel.
Ken wel heel weinig gebruikers van Linux desktops, tenzij ze dit specifiek nodig hebben voor hun werkzaamheden. Ondersteuning is dan wel direct een stuk minder vanuit IT.

Mensen dit raakt weer aardig off-topic in een MS/Ander OS flamewar.
Totaal onnodig.

Iedereen kan prima gebruiken waar hij/zij/het denkt wat het beste aansluit bij de bedrijfsvoering.
Of je nu Toyota of een VW rijdt, ze brengen je beide waar je naar toe wil.

Ik vind 90% besparing wel interessant en dan ook nog een goed werkende ntp oplossing (en cups printserver kado) waar dit topic over gaat. Als een Microsoft verkoper deze mogelijkheid ontkent is het juist interessant.
Ik las de theforeman.org, dat is upstream voor redhat satellite (geen alternatief voor windows beschikbaar). Volgens de MS medewerker zou er geen alternatief zijn voor AD. AD kan je ook met Linux gebruiken maar dat moet je niet doen ivm licentie kosten, stabiliteit en ransomware. Echt veel beter is freeipa.org met je hele $HOME ge-automount (kan niet onder windows, alleen mydocuments en profile). Wij zelf gebruiken nog Graylog & SIEM . Het enige waar we voor betalen is Openshift (incl monitoring), maar dat hoeft niet. Verder zijn we overgestapt van Puppet naar Ansible voor configuratie management. Alle ontwikkelaars en sales gebruiken een Linux laptop. De rest van het personeel een Linux thinclient met een virtuele Linux desktop (spice en NX). Belangrijk is wel dat je goed personeel aantrekt want Linux != Windows.

Dank u, ik heb het meteen uitgezet op mijn DC-en.

FYI: Veel Firewall beheerders zetten inderdaad alles dicht van LAN naar WAN, behalve HTTP(S) en DNS. Ik heb in mijn 30+ jaar als MS systeembeheerder heeeeeeeeeel vaak NTP goed moeten zetten binnen Active Directory omgevingen omdat de meeste collegae beheerders (en firewall beheerders) er niet veel van begrijpen.
Het is vrij eenvouding, en staat hier kort beschreven: https://social.technet.microsoft.com/Forums/windows/en-US/043b1ebe-e7bc-40ca-91e0-174a6854808e/time-sync-best-practices

Het gaat om de discussie enigszins zuiver houden. Start dan een nieuw topic over kosten MS vs Overig OS (Linux etc).
In dit geval is het topic de NTP server of alternatieven op NTP. Dit worden anders altijd ellenlange draadjes, zonder echte conclusies, met onderwerpen die er niet toe doen en de nodige "scheldpartijen". Een uitstapje is prima, maar de OS flamewar neemt het topic weer geheel over.