Dat verbaast me niets, ik zeg al iets van 20 jaar dat de update procedure ruk is bij microsoft. Je moet gewoon kunnen updaten zoals bij linux (kleine packages). Elke keer als ik een CU installeer duurt het lang, verdwijnt 10GB van mijn beschikbare disk ruimte, wordt later weer vrijgegeven, en iets doet het niet.

Moet je voorstellen hoeveel energie wereldwijd verspilt wordt door het onnodig vervangen van binaries, en Billy jammeren over het milieu.

Slecht begin van het nieuwe jaar,
Microsoft waarschuwt op 29 september voor beveiligingslek, brengt 5 weken later een beveiligingsupdate uit, die achteraf niet blijkt te werken.
Is dit amateurisme of wat moet ik er van denken?

Heb je wel gelezen wat er hierboven staat ?

Nou dat update proces zelf heeft men wel goed voor elkaar, het is een transactie dus van alles wordt een copie bewaard
en de hele update wordt "atomic" uitgevoerd: als je hem halfweg cancelled of de machine crashed en reboot dan is alles
nog steeds OK. Daar kan Linux nog wel een puntje aan zuigen, meestal moet je daar toch wel handmatig dingen gaan
fixen als een pakket update halfweg foutloopt.

Wat ik vooral slecht vind is de snelheid van "windows update", dwz de tijd die het kost om te bepalen dat er een update
geinstalleerd moet worden. Het lijkt er op dat alle file versies bekeken worden om te bepalen of er iets moet worden
geupdate, ipv dat er 1 "master" versie is. Hij maakt denk ik eerst een lijst van alle file versies, en vergelijkt die dan met
een lijst die van de windows update server ontvangen is. Veel efficienter zou het natuurlijk zijn om file voor file de versie
op te halen en zodra er een gevonden is die te oud is meteen stoppen en die update markeren als nodig. Het gaat
tegenwoordig wel wat sneller dan voorheen, maar dat komt volgens mij meer omdat men nu veel minder updates
maakt, inderdaad van die grote brokken ipv losse fixes.

Dat "iets doet het niet" komt vooral omdat de laatste tijd de updates vaak niet meer zijn om een coding fout te fixen,
bijvoorbeeld een buffer overrun, maar dat nu de echte design fouten naar boven komen: mechanismen waarbij niet
goed is nagedacht over de veiligheid. Een buffer overrun fix je door een check in te bouwen, en de normale flow wordt
niet beinvloed. Een designfout fixt men door features te disablen, of mechanismen te veranderen, en dan raak je de
normale flow en gaan er dingen stuk, met name als er ook software van anderen bij betrokken is.

Daarnaast moet iedere update worden vrijgegeven wanneer deze klaar is, nu moet je wachten tot een vaste dag die 4 weken later kan zijn.
Verder zou het ook netjes zijn, wanneer alle geïnstalleerde programma's op dezelfde manier ook geupdate worden, zodat je niet voor ieder programma een update traject moet starten.
MS kan nog een hoop leren :-)

Tussen kerst en nieuwjaar een mail van het digital trust center over gehad.
Bleek dat 1 server “vergeten” was te patchen of niet goed gegaan oid.
Direct nogmaals handmatig gedaan, opgelost!

Hij bedoelt denk ik, dat de "tijdelijke fix" totaal niks gefixed had, en niet eens werkte.
Dus hij heeft weldegelijk een punt, maar dat er een patch 2 maanden later pas uit kwam, is wel kwalijk, aangezien het dus 2+ maanden lekker open stond om gehacked te worden...

Je hebt dus geen idee zeg je.
Het gaat hier om een kleine patch niet om een CU

"Nou dat update proces zelf heeft men wel goed voor elkaar, het is een transactie dus van alles wordt een copie bewaard
en de hele update wordt "atomic" uitgevoerd: als je hem halfweg cancelled of de machine crashed en reboot dan is alles
nog steeds OK. Daar kan Linux nog wel een puntje aan zuigen, meestal moet je daar toch wel handmatig dingen gaan
fixen als een pakket update halfweg foutloopt."

check dat nog maar eens even goed.

:D ja ja, ik kan me niet herinneren wanneer ik een update van 3MB heb gezien daar.

Dat het nog steeds niet is gepatcht kan ik mij wel voorstellen want het updatemechanisme is al jaren ruk en als het toevallig in 1 keer goed gaat zijn de settings veranderd.
Wij hebben het zelfs een keer meegemaakft dat de exchange server zichzelf had uitgezet (mailstore te groot geworden) omdat er eerst ge-upgrade moest worden naar een enterprise edition! Deze asociale actie heeft ons doen besluiten onmiddellijk over te stappen naar https://www.open-xchange.com/

En hoe groot was de mailstore geworden?
Of heb je het nu over de SBS uitvoering?

Dat kan ik mij niet herinneren, ergens in de GB's. Was standaard edition. De melding herinner ik mij nog al te goed "Please upgrade to enterprise edition" en de service werd rücksichtslos uitgezet !

Ach, ik kan een boek schrijven over updates op OS of Exchange.

Zelfs situaties meegemaakt dat complete databases verdwenen na een reboot van een upgrade Exchange proces. En een keer dat ineens de database naam compleet anders was. Ja hoor haal adsiedit maar weer van stal....

Dat is wel het voordeel van Exchange Online, dit soort zaken heb je niet zo snel meer. Exchange Online is traag, dat dan weer wel, het gehannis met de AD koppeling.

Maar goed het hoort erbij met MS, ene product als een zak uien en het andere (zoals MSSQL) een bereoed product.

MSSQL is een ontwikkeling van Sybase

Ja nooit geweten dat de 1.0 versie van Sybase kwam. Thanks.

Je weet ook hoe Exchange patched wordt?
Gezien je opmerking, waarschinlijk niet.


Dus "Wij", hebben de monitoring niet in orde, checken niet handmatig eventueel logfiles en weten niet de eigenschappen van onze gebruikte producten. Als wij daarna tegen problemen aanlopen wegens onze eigen onkunde, schuiven we dit af op het product.

Dit bedoel je eigenlijk te zeggen?

Als je dit als beheerder niet weet, als product eigenschap, dan ben je dus eigenlijk ongeschikt als beheerder.

https://petri.com/change_store_size_limits_ex2003_sp2/
Standaard was het limited 16GB, dit was na SP2 te vergroten naar 75GB.


Deze URL spreekt trouwens tegen, dat jij beweerd. Er is eerst een eventlog melding dat de database te groot is, en pas na een 2de melding gaat de store offline.

https://techcommunity.microsoft.com/t5/exchange-team-blog/more-details-on-standard-db-limit-size-increase-in-exchange-2003/ba-p/608086

https://social.technet.microsoft.com/Forums/en-US/01eed052-9ada-47dc-90b5-68d99c5c5b69/exchange-server-losing-connection?forum=exchangesvrgenerallegacy

Pre Exchange 2003 SP2 kon je trouwens ook nog je database vergroten tot 17GB.

Ik vind het ook belachelijk dat exchange zichzelf uitzet zodat bestaande mail niet meer gelezen kan worden.
Zeer klantonvriendelijke leverancier!

Een product service mag zich zelf nooit uitzetten anders is het onbetrouwbare troep. Zegt iets over de kwaliteit van die software.

Als je als beheerder inderdaad incompetent bent, kan dit inderdaad gebeuren. Net zoals bij 100 licenties, de 101 er niet meer in kan.
Of als je licentie tot 1 maart maar geldig is, het op 2 maart niet meer werkt.
Of als je database size het limiet heeft bereikt, dat het daarna niet meer zijn transacties zal verwerken.

Een professionele ITer begrijpt dit en zorg er voor dat zijn omgeving goed en binnen de specs van de applicatie blijft draaien en geeft niet van zijn eigen onkunde of onwetendheid een software product de schuld.

Ik werk genoeg met licentie producten waarbij je gewoon licentie hebt tot een bepaalde periode. Na die periode werkt het niet meer.
Of applicaties die tot een X size mogen groeien, daarna moet je meer betalen en je product werkt niet meer.

Het zegt meer over hoe je monitoring en beheer ingericht is, als dit fout gaat.

NIks met onkunde te maken. Waardeloos bagger product! Een product hoort te blijven werken, ook als de ingebouwde store beperking is bereikt. In dit geval dus ff geen nieuwe mail maar de al opgeslagen mail zou gewoon leesbaar moeten blijven. Een heel slecht ontwerp dus.
Mijn mail server blijft gewoon werken zonder limiet. Ook als het filesyteem vol zit! maar Exchange crasht.

Nee, want als het probleem zich voordoet, kan je dus via een registry aanpassing je server weer in de lucht krijgen en de benodigde opschoonacties uitvoeren.
En een goede beheerder had dit allemaal voorkomen, omdat hij zijn product kent en dus met de eigenschappen reken moet houden.

Fijn voor je. Dus?

Een transactie georiënteerde applicatie zal dit nooit fijn vinden. En een goed product zal zijn consistentie willen bewaren, dus zichzelf afsluiten.

Een goede beheerder had dit natuurlijk ook voorkomen.

Een registry aanpassing ? Man voel je je wel lekker? Ik vind het dan ook een bagger product. Jij hebt duidelijk belang bij de verkoop van dit onzalige product wat crasht als je er naar kijkt. Een goede mailserver heeft trouwens helemaal geen database nodig. Dat is ook een verdienmodel van ms. Zorg dat de producten afh. zijn van mssql dan hebben we een vendor lock gerealiseerd. Natuurlijk kunnen we zo ook de beheerders dan lekker de schuld geven want het ligt nooit aan Microsoft. En ja ik ken de producten. Daarom heb ik er ook afstand van gedaan incl Microsoft monitoring want dat werkt ook niet. Checkmk is ect 1000 keer beter en nog gratis ook.

Heb wel wat last van mijn enkel, maar voor de rest voel ik mij wel goed.

Maar een registry aanpassing, tja, vrij standaard aanpassing, net zoals je ergens een .conf file moet bewerken.

Leuke mening, maar sorry, niet echt professioneel te noemen. Je komt ook niet veel verder dan de standaard onzin argumenten.

Veel meer kan ik er eigenlijk niet over zeggen.

"Leuke mening, maar sorry, niet echt professioneel te noemen. Je komt ook niet veel verder dan de standaard onzin argumenten.

Veel meer kan ik er eigenlijk niet over zeggen."

mja niet om het een of ander mr maar jouw inhoud is ook niet al te bijster.

omdat een DB vol raakt een server laten crashen is inderdaad waanzin en wij went dat zonder verder te blikken of blozen simpel af als een probleem van de beheerder. tss. dan hebben we het nog niet eens over de gestelde limits van 17G voor mail van een organisatie. hier zitten puur commerciële belangen achter en dat ruik je van van om de hoek aan komen!

Grappig....

1: De server crashed niet.
2: De applicatie stop ermee, in een nette graceful shutdown.
3: Heb je meer dan 16G nodig, (Pre E2003 SP2), dan moest je inderdaad een Enterprise licentie nemen, of een 2de server inrichten. In die tijd, heel normaal voor die size icm een bedrijfs grote.
4: En ja Microsoft is een commercieel bedrijf. Niets mis mee. Ondanks dat was het met E2003 SP2 mogelijk om de size te vergroten.

Tja... Echt bijzondere argumenten heb je niet, sorry. Blijkbaar begrijp je niet dat bepaalde applicaties bepaalde technische limitaties hebben. Heel normal zelfs. Zelfs tegenwoordig nog. Dus zo bijzonder is dat niet. Wil je impact voorkomen, moet je daarop monitoren, anders krijg je impact voor je organisatie. Welkom in de grote mensen wereld.