Microsoft Patchday áttekintés () Born IT és Windows blogja

[Német] 2019. december 10-én a Microsoft kiadta termékeinek biztonsági frissítéseinek széles körét. A cikkben található egy áttekintés, amely a frissítésekkel kapcsolatos problémákra utal.

Problémák a Windows 7 rendszerrel

A KB4530734 (havi összesítő frissítés) és a KB4530692 (csak biztonsági frissítés) frissítések legalább szokatlan viselkedést mutattak a Windows 7 ügyfeleknél.

Nagyon hosszú telepítési idő Windows 7 alatt

A Patchday: Windows 7/8.1/Server frissítések című cikkben (2019. december 10.) több blogolvasó beszámolt arról, hogy a Windows 7 frissítések telepítése sokáig tartott (és itt).

Számomra a frissítés csak teljesen megbénította a számítógépemet. A frissítéseket konfiguráljuk egy órán keresztül. És ezt i5 processzorral, 8 GB RAM-mal és 500 GB SSD-vel. Eddig - legalábbis az elmúlt években - a Win7 frissítés mindig néhány perc kérdése volt, és csak a Win10 számítógépem frissítéseinek óráit tudom. Ha ez a "adaptáció" a Win7-ben arra ösztönöz, hogy migráljam a kedvenc PC -imet (eddig) a Win10-re is?

A megjegyzésekben az olvasók rámutatnak, hogy a frissítés telepítése szokatlanul sokáig tart (különösen a frissítések konfigurálásakor).

Ha a gép nem kerül ki a konfigurációs ciklusból, használja a tippemet erről a bejegyzésről, és indítson biztonságos módba az F8-on keresztül. Telepítse a frissítéseket oda.

A KB4530734 fekete képernyővel végződik

A reddit.com webhelyen található ez a szál, amelyben a felhasználó a fekete képernyőre panaszkodik a KB4530734 havi összesítő frissítés telepítése után. A problémát egyes felhasználók megerősítik.

Az e havi Win7 Servicing Stack KB 4523206 frissítés telepítése zárolhatja számítógépét. Csak ezen a ponton ismert javítás a biztonsági másolat visszaállítása. (Nem lehet eltávolítani az SSU-t.) Mondja meg újra, hogyan javulnak az MS javítások? https://t.co/ebbQcourES

Gyanítható, hogy a KB4523206 nem telepített szervizverem-frissítés (SSU) felelős a rendszerindítási problémáért. Woody Leonhard közzétett egy megfelelő bejegyzést (lásd a fenti tweetet is).

Probléma a TrueCrypt alkalmazással

A TrueCrypt kapcsán (amúgy is elavult) úgy tűnik, hogy a titkosított meghajtók rendszerindítási problémáihoz vezet, ahogy itt olvastam.

Windows Server problémák

A Windows Server esetében visszajelzést kaptam a Windows Server 2008 R2 és a Windows Server 2012 mindkét rendszerindítási problémájáról.

Windows Server 2008 R2 rendszerindítási probléma

Az angol blogban ez a megjegyzés található a Windows 7/Server 2008/R2 KB4530734 (havi összesítő frissítés) és KB4530692 (csak biztonsági frissítés) frissítéseiről. Virtuálisgépen a Windows Server 2008 R2 a helyreállítási konzolra megy, és már nem indul el. A gazdagép a VMware.

És ez a megjegyzés megemlíti, hogy a frissítés telepítése után a Windows Server 2008 R2 problémákba ütközött.

Ez a javítás problémákat okozott a Server 2008R2 kiszolgálónknak - az RDP kapcsolat meghiúsult, az DFS névtér szerver nem indult el - a függő kiszolgáló szolgáltatás nem indult el.

Eltávolította a javítást, és minden újra működik.

De lehet egy eset. Ezenkívül nem volt megadva, hogy melyik frissítés okozta a hibát.

Windows Server 2012 rendszerindítási hurok

Ha a Windows Server 2012 rendszerindítási ciklusba kerül a 2019. decemberi frissítések telepítésekor, akkor a .NET-keretrendszer KB4533096 frissítése lehet az oka, ahogy Woody Leonhard a következő tweetben jelzi.

Rendszerindítási ciklusban van a Windows Server 2012 (nem R2)? Hibás a havi .NET javítás, a KB 4533096. Indítson csökkentett módba, és visszahozhatja a szervert. https://t.co/kaEEjOZEgy

Itt is segít a Windows Server 2012 csökkentett módban történő indításában. Ezután a telepítésnek végig kell mennie.

Windows 10: Probléma a hálózati meghajtókkal

A következő tweetben Woody Leonhard rámutat a meghajtók leképezésével (a hálózati meghajtók megosztása) kapcsolatos problémára a KB4530684 összesített frissítéssel kapcsolatban a Windows 10 1903/1909 verzióhoz.

Jelentett probléma a meghajtó-leképezésekkel a hónapos Win10 1909 kumulatív frissítés, a KB 4530684 telepítése után. Úgy tűnik, ez kiütötte az AD-kezelést. Csak az azonosított megoldás a patch visszagörgetése. Meg tudod erősíteni? https://t.co/zHMKLXe9Hv

A frissítés telepítése után a hálózati meghajtók eltűntek, és az AD-kezelő eszközök már nem találták meg a tartományt. A frissítés visszagörgetése megoldotta a problémát. De úgy tűnik, hogy ez egy elszigetelt eset volt.

Az Office 365 frissítéseit visszavonták

Az Office 365 frissítéseiről itt nem beszéltem a blogban. Bizonyos frissítések azonban megtalálhatók a Microsoft Update katalógusban. Bleeping ebben a bejegyzésben arról számolt be, hogy az Office 365 frissítéseit visszavonták. Ok: A frissítések az 0x800b0004 hibát (TRUST_E_SUBJECT_NOT_TRUSTED tanúsítási hibát) váltották ki, amikor SCCM-en keresztül terjesztették őket.

24 válasz a Microsoft Patchday áttekintésére (2019.12.10.)

A nagyon fárasztó számítások miatt nem tudom újraindítani, ezért nem importálhatom a decemberi és januári frissítéseket márciusig, mert a számítások hátralévő időmegjelenítése ésszerűen helytálló, ami korábbi tapasztalataim szerint általában működik. Most az a kérdés, hogy meddig lehet utolérni? Nem mintha a Microsoft az utolsó januári frissítést követően az automatikus frissítéseket teljesen hozzáférhetetlenné tenné a normál felhasználók számára.

Mondana valaki valamit erről?

A Windows 7 régi frissítésének néhány hónapig elérhetőnek kell maradnia. Ezeket azonban letöltheti és elmentheti a Microsoft Update katalógusból. Ezenkívül az összesítő és összesített frissítések tartalmazzák a korábbi javításokat.

Köszönöm, így gyanítom, de soha nem lehet tudni a Microsoftnál.

Természetesen gondoltam a letöltési katalógusra is, de féltem, hogy pontosan mit fog itt találni, például:
http://www.catalog.update.microsoft.com/Search.aspx?q=KB4533095

Mivel rákattintok a letöltésre (középső pozíció x64 esetén), megnyílik egy letöltési ablak, amely négy .exe és két .msu fájlt tartalmaz. Akkor melyik sorrendben telepíti őket? Növekvő KB-számmal? És mikor telepíti először azt, amelyik nincs KB-számmal?

Hogy őszinte legyek, nem vagyok benne biztos. Tudod milyen tanácsot?

A .net katalóguson keresztüli frissítések mindig ilyenek, a KB-nak növekvő lehetne végrehajtani. Először mindig a .msu-t telepítettem, majd az .exe-t. Ezáltal mindig vannak/voltak olyanok, amelyekre az adott rendszernek/hardvernek nincs szüksége, aztán elutasították.
Ezért a WU-n keresztül történő telepítés egyszerűen kevésbé nehézkes, ezért előnyösebb. De működik.
=> DL, először próbáld meg a WU-n keresztül telepíteni, ha ez nem működik, akkor a letöltött fájlok megvannak.

köszönöm!
Igen, természetesen először a Windows frissítést próbálják ki, és csak akkor, ha nem működik (már), akkor ki kell próbálnom a katalógus egyes fájljait, és remélem, hogy az akkor kipróbált sorrendben nincsenek hátrányok, mint pl. B. ezután az újabb fájlokat régebbi fájlokra cserélte, amit még az MS-nek is meg kellett volna tennie.

majd egyszerűen töltse le az utolsó Windows 7 frissítőcsomagot a januári WSUS-Offline-on keresztül, és telepítse vele.
Kérjük, először teszteljen egy másik gépen.

Köszönöm a borravalót! Egyáltalán nem gondoltam a projektre, a Winfuture frissítőcsomagjára, akkor a teljes verzióban, de közben már.

Tragédia, hogy a Microsoft folyamatosan fejleszti termékeit vagy használhatatlanná teszi őket. 20 éve dolgozom Windows rendszergazdaként, ezért sok szenvedést megszoktam, de ez a havi termékminőség-csökkenés valóban az idegeimre esik. Mindig félelem és remény, hogy a saját rendszere frissítésével semmi sem fog rosszul menni, és néhány frissítést egyszerűen nem lehet már telepíteni.
A magam részéről most regisztráltam a Linux adminisztráció tanfolyamaira, és előbb-utóbb megváltoztatom az operációs rendszert. Ha a Microsoft így folytatja, középtávon sokan biztosan ezt az utat választják. A Microsoftnál senkit nem érdekel, mert a Windows arany napja a múlté, és elsősorban a felhőszolgáltatásokra helyezik a hangsúlyt. Ez legalább megmagyarázza, hogy a Windows verziótól függetlenül miért romlik hónapról hónapra.

6 éve vagyok Linux-rendszergazda, de a vállalatnál továbbra is szükségünk van Windows gépekre a speciális szoftverekhez. Az üzleti szférában nem könnyű elkerülni a Microsoftot! A heterogén hálózatban azonban csak a Linux kiszolgálók és a legtöbb ügyfél dolgozik testreszabott Linux Mint 19.1 verzióval. A Windows ügyfelek offline frissítéseket kapnak egy módosított WSUS-t tartalmazó Linux szerveren keresztül. Csak akkor, amikor a W10 tesztgépeken ellenőrizték őket, a bevezetés az irodai időn kívül történik. Jelenleg 2019. december 10-től telepítem a javításokat !

A kötelező újraindítás után a Windows 10 tálcája lefagyott.
Ezt meg lehet oldani a felhasználó kijelentkezésével a „majom fogantyún” keresztül.
Ez egyszeri esemény maradt, amit nem értékelek hibának.

A legutóbbi, decemberi frissítés telepítése után, pontosabban a „2019-12 - Havi biztonsági minőségi összefoglaló a Windows 7 for x86 alapú rendszerekhez (KB4530734)” Windows 7 rendszereim már nem tudtak elindulni, 0xc0000428 mező kód.

Az összes ismert javítási módszer, beleértve a Bootsector vagy a BCD javítását, amelyet ebben az összefüggésben gyakran leírnak, nem jelentenek megoldást.
Később megtudtam, hogy hiányzik a 2019 novemberétől származó KB4523206 ...

Megoldásom: Winload.exe és Winload.efi azáltal, hogy visszalépek a korábban használt verzióra, és várom azt

> Feltételezzük, hogy a telepítéskor nem telepített KB4523206 szervizverem-frissítés (SSU) felelős a rendszerindítási problémáért. Woody Leonhard közzétett egy megfelelő bejegyzést (lásd a fenti tweetet is).

Uh, az ottani problémát nyilván a telepített SSU okozza. Ezenkívül nem újdonság, hogy az MS nem süti le, hogy az SSU telepítve van a kumulatív frissítés előtt. Itt az SSU-t csak a kumulatív frissítés telepítése után kínálták. Nem tudom biztosan megmondani, hogy így volt-e novemberben. De még ott is csak utólag telepítették az SSU-t.

A legutóbbi, decemberi frissítés, pontosabban a „2019-12 - Havi biztonsági minőségi összefoglaló a Windows 7 for x86 alapú rendszerekhez (KB4530734)” telepítése után a Windows 7 rendszereim már nem tudtak elindulni, 0xc0000428 hibakód.

Megoldásom: Winload.exe és Winload.efi a korábban használt verzióra való visszatéréssel és előre tekintve, újratelepítés nélkül B)

Nekem (Win 7 Home Premium) ez teljesen feldobta ezt.

Mivel hetente vannak biztonsági mentések, az utolsót újratöltöttem, majd újra futtattam a frissítést. Furcsa módon gyorsan és tisztán, késedelem nélkül átment. Körülbelül 5 perc múlva minden elkészült.

Nagyon furcsa, számomra a telepítés csak 1-3 percet vett igénybe, mind valós hardveren, mind virtuális gépen.
Minden pontosan a szokásos módon.
Miért van ez a különbség?

[x] A Servicing Stack telepítése először, utólagos helyett
[x] SSD HDD helyett
[x] nincs víruskereső

Mi lehet még releváns?

Most a következő, valódi hardvert csináltam Athlon processzorral, HDD-vel, semmi különöset a Win 7 Ultimate rendszerben:
* Távolítsa el a KB4530734 fájlt
* Telepítse a KB4523206 szoftvert
* Telepítse a KB4531786 alkalmazást

* Azután:
* A KB 4530734 újratelepítése újra létrehozza a hibaképet !

Ha van külső Windows 7 képmentés,
Ezt eljátszanám.
Tapasztalataim azt mutatják, hogy a későbbi frissítések problémamentesen átmennek, és hogy egy rendszer utána jobban működik.

Az SSU-kat mindig visszamenőlegesen telepítették a Windows Update segítségével önálló frissítésként - a Windows 7 Pro rendszeren minden probléma nélkül.

A novemberi KB4523206 és a decemberi KB4531786 SSU-kkal a következőket találtam:
Az SSU KB4523206-ot csak Win 7 Pro gépre ajánlották fel telepítésre, és problémamentesen telepítették.
A többi Win 7 Pro rendszeren nekem nem ajánlottak fel KB4523206-ot.

A Dez-KB890830 frissítés telepítése után felajánlották a Dez-SSU KB4531786-ot, és önálló frissítésként telepítettem minden probléma nélkül.
Hiányzik ezekről a gépekről a KB4523206, de ez nem vezetett frissítési problémákhoz.

Szerintem:
Az SSU frissítés csak a havi KB890830 telepítése után jelenhet meg, még akkor is, ha a Windows Update szolgáltatásban további frissítések várnak.

A KB4523206 nem található a Windows 7 Home Premium 32 Bit SP1 számítógépemen
Telepítve. Ennek ellenére minden decemberi frissítést problémamentesen telepíthettem.
Megpróbáltam telepíteni a KB4523206 fájlt az Frissítési katalógusból
Megkapom az üzenetet: A frissítés nem alkalmas az Ön számítógépére. Így lesz
ez a frissítés nincs telepítve.

A W10 Windows Update csak meg akarta ismételni: „10. 2019. december - Telepítse a KB4530684 verziót (operációs rendszer 18362.535 és 18363.535 buildje) ”a„ W10 Home 1909 ”eszközre! 2019. december 11-én jött.

Töröltem ezt a "szart" - 350-500 MB-ot ismételve mobil kapcsolaton keresztül. Amennyire meg tudom mondani, nincs új verzió?

Ez a "fejlesztés" az új "frissítő kliensen" ....

W10 Home 1909
————————
A "visszaállítási pont" helyreállítása (jelentős változások nélkül) az előző naphoz képest:
kb. 120 perc! Hihetetlen…

Windows 10 Home 1909/18363.535

Intel Celeron N4000/2 mag/max 2,5x GHz
SATA/600

hogy működik valójában az MS-vel a frissítés javításával. Mármint a szeptemberi frissítés feldarabolta az összes kezdőmenüt. A kliensek a mai napig nem működnek megfelelően. Mindig az új hónapra gondoltam. Legalább az ismert problémák frissítése kijavítva.
Így van, vagy hogyan működik ?

Sziasztok
az itt olvasottak arra ösztönöznek, hogy egyre inkább váltsak Linuxra. Még az M $ is ezt gondolja, különben nem tudná futtatni a Linuxot egy ablakban.
boldog Karácsonyt

Üdv mindenkinek,
A Woody Leonhard által írt „Windows 10: Probléma a hálózati meghajtókkal” cikk kapcsán észreveszem, hogy a KB4530684 óta nekem is vannak ilyen problémáim. Különösen 4 régebbi számítógép és i5 vagy gyengébb processzorral rendelkező notebook (az összes Win 10 Pro) gyakran nem hajlandó megfelelő módon bejelentkezni a Win2008R2 tartományi kiszolgálóra indítás után. A szerveren található „felhasználói könyvtár” [Z:] néven van feltérképezve az ügyfélen; de a bejelentkezési szkriptben felsorolt többi meghajtót nem. Ezenkívül a bejelentkezési szkriptek nem érhetők el a \\ ServerName \ netlogon alkalmazással (a hozzáférés megtagadva, bár a felhasználót és a jelszót helyesen kérik és adják meg).
Az egyik notebooknál a WLAN-on keresztül történő regisztráció tökéletesen működik - a LAN-nal csak akkor, ha fix IP-címeket használnak az ügyfél számára.
Ha az ügyfél újraindul, akkor 75/25 esély van arra, hogy a domain regisztráció megfelelően fog működni.
A Woody Leonhard által leírt probléma tehát nem elszigetelt eset, de nem tökéletesen reprodukálható és nyilván hardverfüggő.
Eddig az i7 CPU-val rendelkező újabb számítógépekkel nem volt probléma.
Van valakinek jobb megoldása, mint a KB4530684 eltávolítása?
Előre is köszönöm a javaslatokat.

Hagyj megjegyzést a válasz törlése

Megjegyzés: Kérem tartsd be a szabályokat a blog kommenteléséhez (a kezdeti megjegyzések és a kapcsolódó dolgok a mértékletességbe kerülnek, néhány óránként elengedem őket, szigorúan törlöm a SEO bejegyzéseket/SPAM-eket). Hozzászólások a témához, kérjük, tárgyalja.