Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 40 reacties
Bron: Microsoft, submitter: bierbuik

Windows Server 2003 LogoMicrosoft draait regelmatig stresstests om te kijken tot welke prestaties het bestandssysteem NTFS in staat is en welke problemen eventueel optreden. Tijdens het uitvoeren van deze tests op Windows Server 2003 met service pack 1 geďnstalleerd is gebleken dat in enkele uitzonderlijke gevallen datacorruptieproblemen kunnen ontstaan. Problemen kunnen mogelijk, niet in alle gevallen ontstaat namelijk datacorruptie, optreden als voldaan wordt aan alle vier de volgende voorwaarden: (1) de server heeft meerdere CPU's; (2) er worden 1000 simultane delete-, create- en extendbewerking uitgevoerd op het NTFS-volume; (3) het NTFS-volume is bijna vol; en (4) de server bevat kleine NTFS-volumes. Naar mate de NTFS-volumes groter worden en de I/O-belasting van de server afneemt, daalt de kans dat problemen ontstaan. Aan een hotfix voor dit probleem wordt gewerkt en deze wordt al getest, maar Microsoft wilde toch melding van dit probleem om te voorkomen dat er mogelijk problemen ontstaan bij bedrijven die dit service pack willen uitrollen. Het probleem zou volgens het Redmondse softwarebedrijf niet bij andere Windows-versies voor kunnen komen.

Moderatie-faq Wijzig weergave

Reacties (40)

Geld dit ook voor 1 CPU met Hyper Threading...
In het artikel (http://support.microsoft....aspx?scid=kb;en-us;909360) staat daar niets over. De enige die dat met zekerheid kan zeggen lijkt me MS zélf. Mensen die beweren dat dit zo zou zijn (dus dat het optreedt met HT CPU's) kunnen er langs zitten, want je zult nooit 100% kunnen achterhalen of het dezelfde bug is of een compleet losstaande.

MS is zelf ook nogal vaag in hun artikel (zeker voor hun doen), en ik vermoed dan ook dat ze het probleem dus wel hebben kunnen reproduceren, maar nog niet zeker weten waar het zit. De tijd zal het leren, maar ik verwacht op korte termijn wel een patch (uiteraard ook mede door de "ernst" van de zaak).

Overigens zegt dit, IMHO, weinig over het testwerk van MS. Hoewel ik redelijk MS aanhanger ben, en er van overtuigd ben dat hun testafdeling prima werk levert doorgaans, lijkt me dit probleem dusdanig specifiek en "zeldzaam" dat ze het waarschijnlijk gewoon via klachten van meerdere bronnen hebben gekregen en pas na de x-te klacht begon er een lampje te branden en zijn ze omgevingscondities langs elkaar gaan leggen... _lijkt me_
Dit lijkt mij juist iets wat naar voren komt als je gestuctureerd test. De meeste mensen zullen namelijk niet in eerste instantie aan het OS denken als er schijnbaar op willekeurige momenten data corruptie optreed.

Echter als je een stresstest doet en van te voren weet wat de uitkomsten moeten zijn en die uitkomsten kloppen niet ga je het probleem als bedrijf analyseren. Een klacht als "mijn data is corrupt" van een klant die het probleem ook niet kan reproduceren wordt vaak veel minder serieus genomen.
De meeste mensen zullen namelijk niet in eerste instantie aan het OS denken als er schijnbaar op willekeurige momenten data corruptie optreed.
Het ligt dan ook niet direct aan het OS, eerder aan het bestandsysteem (NTFS), of zo begrijp ik toch uit het artikel, en als er datacorruptie is zou dat idd wel een mogelijke kandidaat zijn.
Het ligt wel aan het OS, als het aan het NTFS had gelegen hadden andere windows versies er ook last van gehad.
MS is zelf ook nogal vaag in hun artikel (zeker voor hun doen),
Sorry? zeker voor hun doen? MS is briljant in het schrijven van vage artikelen of artikelen die maar de helft van de feiten bevatten. Zoek in de support database maar eens naar een willekeurige foutmelding voor Windows XP. Zul je zien dat die foutmelding wél voorkomt in 2000, maar niet in XP. Of wél in 2000 en XP, maar niet in 2003. Terwijl je server op dat moment wel die foutmelding aan het loggen is in de eventlogs...
Goede vraag ... Ik heb overigens nog voor SP1 eens een data-corruptie probleem gehad onder Win2k3 ... Al mijn bestanden waren "wezen" (Orphaned child) geworden ...
Dat nadat hevige netwerkbelasting ... (bestanden van 700 MB werden tegelijkertijd afgehaald via het netwerk en tegelijkertijd werden er weggeschreven ...)
Misschien had je dan toch een bepaalde update van MS binnen, die ook zorgt voor het probleem in SP1?
Maar de gestelde voorwaarden zijn wel erg extreem, ik denk dus dat het niet een groot probleem zal zijn. Wel netjes van MS om het te melden.
Waarom moet er altijd meteen Linux bijgehaald worden als er weer wat "fout" is in een Microsoft product.
(2) er worden 1000 simultane delete-, create- en extendbewerking uitgevoerd op het NTFS-volume
Nummer 2: lijkt me wel zo onwaarschijnlijk dat dit ooit zal voorkomen. dan moeten 1000 mensen precie sop het zelfde moment 1 van deze uitvoeringen doen. Dit kan gewoon niet.

En of er in Linux nooit een foutje word gevonden. Dat word niet meteen van de daken geschreeuwd omdat dat heel normaal is. :?
En of er in Linux nooit een foutje word gevonden. Dat word niet meteen van de daken geschreeuwd omdat dat heel normaal is.
Tja, laten we maar niet beginnen over de datacorruptie in de 2.4 reeks van de Linux kernel (2.4.11-dontuse enzo). ;)
Ik vind het een nette afhandeling van MS :)
1000 mensen precies hetzelfde doen? :?

Dat slaat nergens op, een druk belaste database of indexing server heeft makkelijk zoveel bewerkingen gelijktijdig.
Niet alleen mensen benaderen files hoor, er bestaat ook nog zoiets als applicaties.
Rare beredeneringen houd jij er op na ;)

Evengoed zal het concrete risico klein zijn, maar de impact is wel knap groot te noemen.
Lees eerst de KB eens:
If a scenario is very different, the chance that this corruption will occur is very low. For example, the problem is very unlikely to occur if the following conditions are true:
A server has very large volumes.
Few delete, create, and extend operations occur.
Database operations typically involve I/O with previously allocated files.
Je kunt nu eenmaal niet alles 100% testen. Ik vind het eigenlijk wel netjes dat ze een fout die bijna nooit optreedt toch melden in plaats van gewoon niets te zeggen en op het beste te hopen.

Natuurlijk is dit ook in hun eigen belang, want als ze niets zeggen en het komt uit, dan schaadt dat het vertrouwen en dat is waarschijnlijk veel erger op de langere termijn.
Denk na.. Het gaat om zeer uitzonderlijke situaties. Je kan bijna zeggen dat dit in de praktijk niet voorkomt. Als het al voorkomt dan is het nog niet eens echt een probleem als je de zaakjes op orde heb.

Niks aan het handje dus.
Wat een VOLSLAGEN onzinnige uitspraak.
Microsoft komt zelf met het probleem en werkt aan een oplossing, de kans dat iemand dit probleem kan hebben en het merkt is klein.
Ik vind dit alleen maar een goede stap van microsoft door zo goed te testen en er bekenheid aan te geven.

Ik zie het al voor me:
Microsoft heeft een probleem ontdekt waar vrijwel niemand last van heeft en werkt aan een hotfix, laten we gelijk migreren naar Linux
:?
backslash:

al *zou* een certificate verlopen, waarom moet je dan opeens 2 uur wachten voor ene restart ? En wat denk je ervan als bij de een de tape drive niet meer werkt, bij de tweede de hele network stack niet meer werkt, bij de 3e mail wel werkt maar de proxy niet... etc.

Het gaat niet direct om het wel of niet verlopen zijn van een certificate -- het gaat er om dat er fundamenteel iets mis met je OS is dat het zo'n zooitje wordt als er een certificate verloopt waardoor een of andere service niet, of niet op tijd gestart wordt.

Ander voorbeeld: als je een WINS server optuigt, krijg je nogal eens dat "the allotted time to start" overschreden was en windows niet zeker weet of de service wel of niet gestart is.

Moet je het gewoon nog een keertje doen.

of wat dacht je van "SQL server has PID 443" in je event log. interessant gegeven. onder usix zijn er inderdaad een aantal processen die dezelfde PID hebben het hele jaar door maar interessant is het niet. ga je kijken wat je hier mee moet. staat er dus geen reet in de event log wat je er mee moet. wel een lnk, die je aanklikt waardoor je op een website van SM komt die dan roept dat de gegeven event niet bekend is...

Over exchange die niet op een DC mag draaien..... dat mag wel degelijk en voordat je het vergeet. SBS 2003 wordt exact in die config geleverd ... speciaal om dat te doen. daarnaast moet je je ernstig af gaan vragen wat voor een stuk ellende exchange wel niet moet zijn als je een DC + exchange een systeem op zijn knieen krijgt.

ook op dat vlak kan ik dan kort zijn ... met minder hardware meer kunnen doen met een ander OS en stabieler ook. waarom kan MS dat dan niet ??

het verbaast me elke keer weer dat er mensen zijn die iets 'normaal' vinden. zoals dat een DC plus exchange niet op ene enkele doos past. of dat exchange eerst t=gesloopt moet worden alvorens je restart omdat AD te snel dood gaat. of dat je bijvoorbeeld een defaukt route aanpast en dat *&%(*&%*(&*)& t(*^()* moet restarten zo midden op een dag. of dat je out of memory raakt. oh wij restarten de server gewoon elke week. dat soort dingen. het is gewoon niet normaal dat je dat accepteert. tenzij je natuurlijk niet bekend bent met andere producten die dat soort beperkingen niet hebben....

zo maar wat gedachten over het een en andere. en nee, ik ben geen fan van W2k3. het levert sloten meer geld op voor ons werk, dat wel. maar de sh*t die je er van hebt is ook ernstig groter. *ik vind het NIET normaal*.


Event Type: Information
Event Source: MSSQLSERVER
Event Category: (2)
Event ID: 17177
Date: 10/29/2005
Time: 11:00:54 PM
User: N/A
Computer: [...]
Description:
This instance of SQL Server has been using a process id of 1344 since 10/26/2005 1:18:36 PM (local) 10/26/2005 11:18:36 AM (UTC).

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.


en nu even voor de gein naar 17177 kijken:

Details
ID: 17177
Source: MSSQLSERVER

We're sorry
There is no additional information about this issue in the Error and Event Log Messages or Knowledge Base databases at this time. You can use the links in the Support area to determine whether any additional information might be available elsewhere.


--------------------------------------------------------------------------------


Thank you for searching on this message; your search helps us identify those areas for which we need to provide more information.


en zo kom je dagelijks (maar daarvoor moet je wel eerst je ogen open doen en ervaring met systemen hebben die wel btrouwbaar zijn) van dit soort gezeur tegen waarvan je je echt zit af te vragen of ze wel goed snik zijn daar in redmond.
knap hoor zo positief reageren op dit bericht.
ik draai sp1 al een jaar uit aan klanten, en vind dit toch een behoorlijk cruciale/jammerlijk bug.

vind het tegenvallen juist omdat ik niet zo veel hele serieuze bugs meer tegenkom, en deze zou dramatisch (kunnen) zijn in een grote omgeving.
Vind je? De kans dat dit in het wild gebeurt is nihil. Ten eerste moet het system continue voor meerdere uren zeer zwaar belast worden en ten tweede moeten de volumes kleiner dan 24GB zijn. Disken van 18GB zijn al jaren niet meer leverbaar bij bv Compaq/HP en Sun. En de hoeveelheid IO die er op het systeem moet zijn is dermate hoog dat je dat in de praktijk niet of nauwelijks continue tegenkomt.

Als je deze situatie wel tegenkomt, dan draai je waarschijnlijk een systeem dat zowat kreunend tot stilstand komt en smeekt om een upgrade en waarschijnlijk zo oud is dat je er waarschijnlijk ook geen W2K3 op hebt draaien.
Al eens bedacht dat 1 disk meerdere volumes kan bevatten?
Voor sommige toepassingen wil je juist geen grote volumes, en dat heeft niks met de ouderdom van een systeem te maken.

En van 1000 simultane bewerkingen schrik ik nou ook niet echt, ik zie dagelijks genoeg systemen die het wel halen.
De kans dat je idd 1000 simultane acties ziet op een server is echt heel erg klein.

OK, ik heb ook een aantal systemen die makkelijk boven de 1000 file-operations per seconde doet. Maar dat is niet simultaan. Daarvoor heb je heel wat meer operations per seconde voor nodig en dus een hele volle disk-queue.

Dit zul je vrijwel nooit in een live omgeving zien aangezien dit betekent dat de server een hele slechte performance heeft bekeken vanuit menselijke acties.
Voor een data 'verwerkings' systeem is dit minder een probleem tijdens piek-tijd; echter dit soort acties zijn met slechts een aantal uitzonderingen transactioneel, zodat de kans op uiteindelijke data corruptie nog kleiner wordt.
In een datawarehouse-omgeving kan dit probleem zich voordoen tijdens ETL-processen, i.e. wordt al redelijk vlot voldaan aan de voorwaarden, helemaal als je om performance redenen je TEMPDB op een apart volume onderbrengt. In dat kader wordt interessant wat bedoeld wordt met 'extend operations'. Als dit de autogrow functionaliteit is, kan een dolgedraaide query die TEMPDB benut al voldoende zijn...
ik draai sp1 al een jaar uit aan klanten, en vind dit toch een behoorlijk cruciale/jammerlijk bug.
Ik dacht dat ie pas sinds mei uit was ofzo? Half jaartje dus.
Lekkere systeembeheerder ben jij dan, als jij je klanten op beta's laat draaien :Z
refriednoodle:

ja van exchange weet ik dat wel, omdat AD eerder afgeknald wordt dan de exchange componenten. Het geeft alvast aan dat een simpele start/stop volgorde bij MS al ernstig te hoog gegrepen is.

Ik geef alleen maar aan dat MS basale zaken al niet op orde heeft. Vreet alle memory maar eens weg. een OOm killer -- nooit van gehoord. Garbage collectors -- nooit van gehoord. Normale defaults voor w3proxy -- nooit van gehoord. Duw maar eens 8 GB in een systeem en laat dan w3proxy met default values starten. Werkt dus niet.

Dat soort zaken werkt irritaties in de hand. Jouw opmerking "ervaren exchange admins weten dat...' geeft precies het probleem aan. MS admins schijnen het allemaal normaal te vinden dat je voor van alles en nog wat kunstgrepen moet uithalen. In plaats van dat dat soort bugs opgelost worden....

Herinner je je nog het APC debacle ? Ook zo'n probleem met het starten van services.
Over dat APC debacle:

Waarom hebben andere fabrikanten van UPS apparatuur dan geen problemen opgeleverd? Die maken immers gebruik van dezelfde door APC notabene ontwikkelde techniek die MS weer als API aanbiedt.

en even voor de duidelijkheid, het punt van een UPS is dat bepaalde services daarop dependant worden gezet om je servert netjes te kunnen afsluiten.

Dat APC zo stronteigenwijs is om een certificaat te laten verlopen en diens klanten daarvan niet voor te waarschuwen kan je MS niet verwijten.

Exchange:
Ik zei het eerder ook al; eigenlijk wil je Exchange ook niet op een DC hebben draaien. Om een heel simpele reden, namelijk performance. Je draait twee database pakketten op dezelfde server.
Das LVT (leuk voor thuis) of voor kleine omgevingen <50 man maar niet aan te raden.
"Het gaat niet direct om het wel of niet verlopen zijn van een certificate -- het gaat er om dat er fundamenteel iets mis met je OS is dat het zo'n zooitje wordt als er een certificate verloopt waardoor een of andere service niet, of niet op tijd gestart wordt."
Je kan je ook afvragen waarom, hoe het kan dat 1 applicatie zoveel shit kan veroorzaken. Misschien is het wel de applicatie zo brak ontwikkeld en geschreven dat dit daardoor allemaal komt?

Neem bv eens de SonyRootKit die momenteel veel ophef geeft. Dit is een applicatie die ook geschreven is door een 3de partij. Dit is echter zo slecht gedaan dat je er meer shit mee krijgt dan dat je zou willen. Licht dit aan micrsoft of de programmeur die zich niet aan de regels heeft gehouden.

Een Windows server iedere week herstarten, dat doen we al niet meer sinds windows 2000. NT4.0 draaid bij ons ook zonder problemen en herstarten doen we echt niet aan. Zolang het maar alleen NT40 Apps er op draaien. Als we een NT server moeten herstarten is het meestel omdat een andere applicatie is gecrashed (SQL, BlackBerry, Cisco Radius, of andere troep). Memory leaks komen op het OS nivo bijna niet meer voor. Vanaf windows 2000 kunnen we toch wel zeggen dat het OS redelijk stabiel is. Over windows 2003 hebben we zo wie zo weinig te klachen. Het is een goed OS, maar nog niet af.

OP je DC en Exchange opmerkingen:
Volgens mij is het alleen maar een advies dat microsoft geeft om geen DC en Exchange op de zelfde box te draaien. Ik heb zat servers geinstalleerd die al maanden zonder problemen draaien.

Op jou "For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.&quot; opmerkingen. Tja de MS knowigebase bevat natuurlijk niet ieder eventID. De link is gemaakt voor n00bs die het wel gemakkelijk vinden. Een echte beheerder gebruikt toch al sneller google of eventID.net. En ik heb oko vaak genoeg gehad dat die meteen naar het goede antwoord ging.

"ook op dat vlak kan ik dan kort zijn ... met minder hardware meer kunnen doen met een ander OS en stabieler ook. waarom kan MS dat dan niet ??"
Ik kan hem ook omdraaien, met Betere hardware en een ander OS, kan ik ook meer. En dan heb ik een nog stabieler platform, wat veel verder ontwikkeld is en nog stabieler, daar kan jouw advies nog niet eens tegen op. Het is maar hoe je het wilt zien.
>Je kan je ook afvragen waarom, hoe het kan dat 1 applicatie zoveel shit
>kan veroorzaken. Misschien is het wel de applicatie zo brak ontwikkeld
>en geschreven dat dit daardoor allemaal komt?


als jij vindt dat een OS ondreuit mag gaan omdat een applicatie den weg
kwijt is, dan vind ik dat prima. Dat is namelijk wat je zegt. Dat is
toch echt een basis die je mist. Daarnaast had APC wel gewaarschuwd maar
als je google'd dan kom je zat bedrijven en mensen tegen die ene hoop
shit opgelopen hebben erdoor. en nogmaals: het is niet de applicatie,
maar het OS dat daardoor in de prak loopt.

>Neem bv eens de SonyRootKit die momenteel veel ophef geeft. Dit is een
>applicatie die ook geschreven is door een 3de partij. Dit is echter zo
>slecht gedaan dat je er meer shit mee krijgt dan dat je zou willen.
>Licht dit aan micrsoft of de programmeur die zich niet aan de regels
>heeft gehouden.

>NT4.0 draaid bij ons ook zonder problemen en
>herstarten doen we echt niet aan. Zolang het maar alleen NT40 Apps er op
>draaien. Als we een NT server moeten herstarten is het meestel omdat een
>andere applicatie is gecrashed (SQL, BlackBerry, Cisco Radius, of andere
>troep).

dus MSSQL is geen windows NT4 applicatie ? Op een fatsoenlijk OS restart
je de applicatie die op zijn bek gegaan is. niet restarten.

>Memory leaks komen op het OS nivo bijna niet meer voor. Vanaf
>windows 2000 kunnen we toch wel zeggen dat het OS redelijk stabiel is.

Heb je de release notes van SP1 al eens goed bekeken ? Daar zitten
verschillende memory leaking comonemnen bij die gefixed zouden zijn.

>Over windows 2003 hebben we zo wie zo weinig te klachen. Het is een goed
>OS, maar nog niet af.

Helemaal niet af bedoel je. Sluit je ogen niet voor de ellende die er in
zit. er kan zoveel mis gaan met dat systeem waarvan je met fris verstand
niet bij kan -- dat kan je nooit ene goed OS noemen. of je moet geen
hoge eisen stellen.


>Volgens mij is het alleen maar een advies dat microsoft geeft om geen DC
>en Exchange op de zelfde box te draaien. Ik heb zat servers
>geinstalleerd die al maanden zonder problemen draaien.

Tja, ik verzin zoiets ook niet. ik snap best wel dat sommige zaken niet
samen willen maar exchange/DC is in mijn ogen geen probleem. het vreet
wel een hoop memory weg en dat kan ene probleme zijn. bij windows 2003 is
het dan ook standaard net voor een crash (vaak memory tekort) exchange
luistert niet meer, VPN's connecten nog. en dan peens niet meer in
kunnen loggen. VPNS dood, proxy gaat er aan, systeem reageert alleen op
pings. grijs scherm, keyboard dood (reageert niet meer op ctrl/alt/del
etc). mouse pointer kan je nog bewegen maar de screen saver doet niks
meer.

>Op jou "For more information, see Help and Support Center at
>http://go.microsoft.com/fwlink/events.asp."; opmerkingen. Tja de MS
>knowigebase bevat natuurlijk niet ieder eventID.

inderdaad. MS is de maker dus waarom zouden ze hun eigen data compleet
hebben, niet ? en stel dat het useless info is (events zijn dat meestal
wel trouwens, over logging, gesproken.. nog zo'n grote afwezige), waarom
zit het er dan nog in ?

>of eventID.net. En ik heb oko vaak genoeg gehad dat
>die meteen naar het goede antwoord ging.

http://eventid.net/display.asp?eventid=17177

al bekeken dan ? ik pik niet zomaar dit event er uit.....

>Ik kan hem ook omdraaien, met Betere hardware en een ander OS, kan ik
>ook meer. En dan heb ik een nog stabieler platform, wat veel verder
>ontwikkeld is en nog stabieler, daar kan jouw advies nog niet eens tegen
>op. Het is maar hoe je het wilt zien.

het is anders precies het advies wa wij geven steeds aan de mensen die
windows servers hebben staan. om de tco/roi te verlagen, kiezxen wij
voor concepten die wel doorontwikkeld zijn. en dat is geen windows.

het is maar hoe je het wil zien. wij denken mee met de klanten en
proberen te verhoeden dat ze in het dure onbetrouwbare MS-vangnet
verstrik raken.

sommigen zien het in, sommigen niet.....

wel bewijzen we met conversies van windows af, dat het inderdaad beter kan.
Ik zie er ook niets positiefs in. Moet je toch wel een beetje de weg kwijt zijn hoor.

Serieuze bugs genoeg. OOM situaties zijn nog steeds een drama, alsmede van die vage hangende applicaties zo her en der. (met name de snap-ins). Ook hebben we het niet over de sh*t die optreedt als een service niet goed opstart (denk even terug aan een verlopen certificate van een APC product -- je hele systeem loopt op een hoop). En dan nog de ellende die je op je hals haalt als je SP1 later installeert. Niemand die weet of je systeem goed blijft werken, of die nog wil booten, noem maar op.

En een DC/Exchange/Fileserver die een kwartier er over doet om te restarten is ook niet echt normaal te noemen. Of wat dacht je van inconsistencies in de AD ? Je zoekt je de blubber als een imap account niet wil werken omdat er op de een of ander manier twee Aliassen gelijk zijn. En zo kan ik uren doorgaan.

Heel windows 2003 valt tegen, qua prijs, performance, reliability, monitoring. manageability.
En een DC/Exchange/Fileserver die een kwartier er over doet om te restarten is ook niet echt normaal te noemen.
Ervaren Exchange-beheerders weten gelukkig dat je ook eerst handmatig de Exchange SA moet stoppen voordat je een server shutdownt of reboot. Scheelt een kwartier of meer.
Alleen als dat ook een DC is.
Best practice is dan ook om Exchange niet op een DC te zetten.
Kan wel, alleen krijg je dan je voornoemde "probleempje".
Die "Best Practice" gaat meestal niet op in een SBS oplossing bij kleine ondernemingen met 15 medewerkers

Maar idd, er zijn zat dingen inhoudelijk te vinden die vertellen dat je eerst Exchange services moet stoppen voor je een dergelijke server reboot.- Dit is meen ik me te herinneren overigens een onhebbelijkheidje wat naar mijn weten iig ook in de Windows 2000/ Exchange 2000 combi zat.

Windows 2003 valt me 100% mee. een beste performance, beduidend stabilere omgeving - issues daargelaten die uitstekend waren op te lossen - monitoren gaat me best af, en remote management is ook aanzienlijk verbeterd t.o.v. 2000.

Er zitten wat mindere puntjes aan SP1, waardoor ik nog niet live er mee werk. Zo zit er een geheugen management issue in wanneer er gebruik wordt gemaakt van Terminal Services. Da's voor ons een showstopper geweest, en dan hebben we nog het probleem dat ik nogal lang moest wachten op de nieuwe Dell Open Manage omdat de 4.3 en voorgaande versies niet geschikt waren voor SP1 - maar dat mag je MS niet verwijtn.
Nou ben ik ook geen geweldige MS fan, maar ze kunnen het gewoon nooit goed doen.Wat had jij dan gewild?Moet MS dan maar geen tests meer uitvoeren, of de boel doodzwijgen?Ik vind het netjes dat ze deze bug überhaupt gevonden hebben en nog beter dat ze met een waarschuwing komen.Dat er nog -tig andere bugs zijn doet daar niks aan af ;)
Da bijzonder tof ;(

Gezien het feit dat het redelijk laat ontdekt/openbaar gemaakt wordt (SP1 is toch al even uit), zal de kans dat het effectief fout gaat wel redelijk klein zijn. Dit wordt nog eens bevestigd door de 4 voorwaarden? Maar toch, je wil niet de systeemeheerder zijn als er door zo'n patch ineens een paar gigabyte aan data corrupt is geraakt.
Wie weet merk je het niet eens voor je backup-retentie verstreken is :o
Dit zul je niet geloven, ben gewoon thuis aan het overwerken omdat we vaak datacorruptie problemen hebben op een server van ons met daarop uiteraard Windows 2003 SP1... |:( |:(
Laatst zelfs de hard disks vervangen.
Nu maar hopen dat er SNEL een patch komt.
Gelukkig heb ik nu een idee waar het aan kan liggen...
De kans dat deze fout optreedt mag dan nihil zijn, men kan software niet statistisch gaan beoordelen. Software is geen lottomachine. Een bug is een bug en moet opgelost worden.

Deze fout is een typische multi-thread bug. Zo heb ik er nog wel een aantal gezien in Windows.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True