Windows 10 will kill off 'Patch Tuesday'

http://www.pcworld.com/article/2920158/windows-10-will-kill-off-patch-t…

ez remek dolog lesz, most már nem havi 1x fog ledögleni gépek nagy része.
2015 ben már kb. 1 db. updatet se tudnak kiadni úgy hogy ne kérjen reboot ot a szerver/kliens. majd pont win10-ben persze :)
Marketing szöveg amit a ms fejlesztőkkel nem közöltek, majd megoldják valahogy.
max megnő majd a frissitések száma amit vissza kell vonni :D

Hozzászólások

A Linux kernelben bemutatkozott live-patching itt is jól jönne nem? :D

> most már nem havi 1x fog ledögleni gépek nagy része

Ezzel kapcsolatban érdemes végiggondolni, hogy ha minden patch-kedden meghal az infrastruktúra, az biztosan vendor hiba-e.

Hogy tesztelitek a frissítéseket, mielőtt élesbe külditek őket?

Hogy tesztelitek a frissítéseket, mielőtt élesbe külditek őket?

És ti? ;) Ráadásul pont ezen héten rosszul jön ki, hogy felteszed ezt a kérdést: http://news.softpedia.com/news/Windows-Stuck-on-Configuring-Windows-Upd…

Szerk.: Amúgy - és ezt most komolyan kérdezem - egy ilyet, hogy tudsz tesztelni élesbek küldés előtt? Nem egyértelmű, hogy mi okozza (nálunk teljesen változó, hogy melyik gépeken jött elő, HW és SW terén is elég változatos a felhozatal), így vagy minden lehetséges konfiguráción tesztelsz minden update-t, vagy... a legjobb tippem, hogy WSUS, és váratsz két hetet, hogy mások belefutnak-e bármibe.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Annak ellenére, hogy természetesen úgy ajánlott, mint bevett gyakorlat minden tervezett változtatást homokozóban lepróbálni, a személyes véleményem az, hogy visszatetszést kelt az a magatartás, amely egyfolytában meghazudtolni próbálja az ügyfelet a felelősséget áthárítandó - különösen ilyen stílusban kommunikálva mindezt. Azt, hogy ennek kivételesen hangot adtam, _NEM_ trolltápnak szánom.

------------------------
Program terminated
{0} ok boto
boto ?

A fenti posztommal nem jzola szavahihetőségét akartam kétségbe vonni. Arra próbáltam utalni, hogy ha valahol _minden_ patch megöli a rendszert, akkor ott nem biztos, hogy a vendor a hibás.

Nyilván mi is hibázhatunk, ahogy az összes másik IT cég: néha valóban becsúszhat olyan patch, aminek nem kellene. De nehogy már az derüljön ki a végére, hogy szó szerint minden kiadott patch rossz, és megborítja a rendszert.

De nehogy már az derüljön ki a végére, hogy szó szerint minden kiadott patch rossz, és megborítja a rendszert.

Ez természetesen nincs így. De az utóbbi időben már tényleg többen véltek felfedezni egyfajta trendet a visszavont, vagy különböző szolgáltatásokat megtörő frissítések számának növekedésében.

Azzal együtt is, hogy lehet, hogy darabszámában lehet, hogy ugyanannyi, mint egy RH/Novell/Canonical/akármi, viszont a felhasználói bázis mérete miatt több embert érint.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Lásd a véleményem lentebb: pont a felhasználói bázis nagysága miatt fizikailag lehetetlen minden szóbajöhető szoftverkörnyezet (a példánál maradva a Cisco akármelyik termékét) a Microsoft oldaláról tesztelni.

A félreértések elkerülése végett mégegyszer: nem azt próbálom bemagyarázni, hogy nincs hibás patch, mert nyilván van.

Ha "mi" alatt a Microsoft-ot érted, akkor nem csúszhat be olyan, hogy egy 10-100 milliók által használt Cisco AnyConnect-el nem teszteltek le frissítéseket (ugye a dolog pikantériája, hogy a VPN-en dolgozó kollégák ezáltal elérhetetlenné válnak).
Ekkora nem hibázhatok.

Nem ismerem a release processt, de józan ésszel végiggondolva a lehetőségek száma miatt legfeljebb azokkal a 3rd party szoftverekkel lehet tesztelni vendor oldalon, amit _milliárdok_ használnak, nem százmilliók. (Amúgy laikusként kérdezem, ez nem egy költői túlzás volt?)

Ekkor jön be a házon belüli tesztelés: mielőtt bemehet a patch az éles infrastruktúrába, meg kell nézni, hogy a helyben használt megoldásokkal kompatibilis-e.

Átfogalmazva: gondold végig, tudsz-e listát adni olyan 3rd party szoftverekről, amit a Microsoftnak külön tesztelnie kellene minden egyes patch előtt?

Lát(hat)ja a rajta futtatott üzleti kritikus alkalmazásokat, ebből készíthető lista a legtöbbször előfordulókkal.
Ezeknek és a távoli menedzsmentet lehetővé tevő szolgáltatásoknak biztosan be kell kerülnie.
De az eset legalább nyilvánvalóvá tette, hogy 3rd party alkalmazásokkal abszolút nem foglalkoznak (persze jó párszor házon belüli alkalmazásokat is sikeresen kinyírtak).

Azt gondolom, hogy elég drágák az Enterprise változatok ahhoz képest, hogy a fenti tesztelést teljes egészében kihagyják és rátolják felelősséget a vásárlóikra.

Nem mindenhol hasal el. Es nem 100% homogen hw krol van szo. Hibara En pl arra gondolok hogy egy .net frissites gyengebb gepeket neha megfekteti rendesen. De most pl ezen a heten volt olyan hogy gepek beragadtak a configuring updates be... Es nem mindegyik ...

Egyebkent erdekelne hogy teszteled ezt pl le. Ok hogy ott a wsus de nem hiszem hogy realis hogy updateket egyesevel atnyalazod havonta(es 10 tol majd naponta?). Gondolom wsus atlag felhasznalo frissites utan+1 het ranyomja egy gepre nincs gond akkor meg osszesre.

Egy érettebb IT szervezetben kéne, hogy legyen change management folyamat - legalábbis papíron. :) Ez független a Windows Update-től, mert ideális esetben az OS update-ek elég kis részét adják a problémás változásoknak.

Ha én felelnék egy cég infrastruktúrájáért, biztosan nem merném (szó szerint: nem lenne meg hozzá a bátorságom), hogy tesztelés nélkül kiengedjek valamit WSUS-on, de ugyanígy nem engedném látatlanul release-elni az egyedi fejlesztések új verzióit.

"Ez független a Windows Update-től, mert ideális esetben az OS update-ek elég kis részét adják a problémás változásoknak."

A gyakorlatban pedig nekünk (nagyválallati IT - Microsoftos csapata) a munkánk jelentős - indokolatlanul nagy - részét adja a Microsoft Update/WSUS/WSUS Agent hibáinak javitása.
Nyugodtan ki merem jelenteni, hogy a mechanizmus az egyik leggyengébben sikerült szolgálttása a Microsotnak, az Office Communicator/Lync és a HyperV hálózati hibáival vetekedhet.

Kevés helyen van - főleg itthon - komolyan vett change management, KKV-s IT jellemzően túlterhelt, nincs rá erőforrás.

Ez oké - minden ellenkezést értek, amit már elég sokan megfogalmaztak e threadben. Én az OP állítására reagáltam, miszerint havonta egyszer elesik a gépek jórésze, kifejezetten a MS patch-ek miatt.

tl;dr, és ez igaz az egész threadre: azt elhiszem, hogy _néha_ a MS hibájából problémás az update-ek telepítése, de hogy _mindig_, azt bocsánat, de nem. Ahhoz szerintem már a felhasználó proaktív hozzájárulása is kell.

A _néha_ azért erős szépítése a dolgoknak. A _gyakran_ talán kicsit jobban leírja, fórumokat olvasgatva és egyéni tapasztalatok alapján.

Teljesen tiszta, csak Microsoft terméket (Office és VS2013) tartalmazó, időnként bekapcsolt Windows 8.1 rendszeresen elhasal update installálásokkor. Indokot nem sokat ad.

Mit értesz "proaktív" alatt? Azt, hogy rendeltetésszerűen használok egy rendszert?

Értsd: alkalmazások telepítése, nyilvántartása és frissítése mind a mai napig kritikán alulian van megvalósítva a Windows rendszeren.

"Értsd: alkalmazások telepítése, nyilvántartása és frissítése mind a mai napig kritikán alulian van megvalósítva a Windows rendszeren."

Erről viszont nem a Microsoft tehet és így általánosságban nem is igaz.
Van, ami évekkel megelőzte az alternatív rendszerek képességeit és adott volt a lehetőség a szállítóknak, hogy ne a saját összebugázott installer-jeiket részesítsék előnyben, hanem a Microsoft megoldásait.

> Teljesen tiszta, csak Microsoft terméket (Office és VS2013) tartalmazó, időnként bekapcsolt Windows 8.1 rendszeresen elhasal update installálásokkor. Indokot nem sokat ad.

Patchet elhasalni láttam már, nem is egyet, de ilyet, ráadásul rendszeresen, még soha. Biztosan nincs ott más baj a géppel? Vagy nem tudom, ezt így elég nehezen tudom elképzelni. :(

Elég egy szerencsétlenül félresiklott frissités, a függőségi viszonyok miatt a következőt is esélyes, hogy roll back-elni fogja.
Vagy mondjuk .NET regisztrációs hiba, ugyancsak failed-re fognak futni a ráépülő update-k.
Érdemes a %WINDIR%\windowsupdate.log-ot nézegetni.