Archívum

Posts Tagged ‘wsus’

Újabb szög a Windows 2003 koporsójába

május 2, 2018 2 hozzászólás

A rendszergazda kollégák tudják, hogy egy vérbeli IT szaki nagyon ritkán van “kikapcsolt” állapotban – főleg abban az esetben, ha több rendszer is van a felügyelete/támogatása alatt. Sőt, továbbmegyek: mivel az informatikusok akkor dolgoznak, amikor a többiek pihennek (nem igazán lehet karbantartást végezni, miközben a kollégák végzik a munkájukat), a hosszú hétvége remek alkalom a teendők végrehajtására (pl. a végre kijött 1803 tesztelésére 😉 ).

Ennek fényében nem csodálkoztam, amikor egyik helyen a kollégák “megnyomták a piros gombot”: szerették volna a kezük alá tartozó rendszereket frissíteni, viszont adott cégnél meglepődve tapasztalták, hogy a Windows 2003 R2-re alapuló WSUS kiszolgáló március 30-án reggel még sikeresen, délután már sikertelenül csatlakozott a MS Update szerverekhez – s azóta folyamatosan sikertelen volt.

A hibaüzenet nem volt teljesen egyértelmű:

WebException: The underlying connection was closed: An unexpected error occurred on a send. —> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. at System.Web.Services.Protocols.WebClientProtocol.GetWebResponse(WebRequest request)

Igaz, hogy az MS saját leírásaiban sem teljesen következetes a WSUS működéséhez szükséges, tűzfalon kiengedendő portokat és célokat tekintve, a tapasztalat azt mutatja, hogy a sima http protokoll nem elég, szükséges a https is – itt viszont egy csavar kerül a történetbe, ami magyarázatot adhat a probléma gyökerére.

A https esetén nem csak a tanúsítvány állapotára kell figyelni, hanem a használt protokollra is. Nos, a Windows 2003 elég régi termék, csak az 1995-ben megjelent SSLv2, az 1996-os SSLv3, illetve az 1999-es SSLv3.1/IETF-féle TLS 1.0-t támogatja (a 2006-os TLS 1.1 és újabbakat nem). Nos, eredetileg 2018 június 30.-ra volt tervezve a régi protokollok kivezetése és a TLS1.1 alappá tétele, de ezt előbbre hozták, április 30.-ra. Fentiek fényében a WSUS azóta új frissítéseket nem tölt le, megoldás vagy egy proxy lehet, vagy természetesen egy korszerűbb rendszer.

Megj: bármikor nyitott vagyok privátban megvitatni azt, hogy valaki miért használ még elavult rendszereket, de itt szakmailag tárgyalom a témát…

Windows Update – no updates

április 17, 2013 Hozzászólás

A múltkori ügyfélnél ismét segítségre volt szükség. Adott gépen volt egy érdekes jelenség: grafikus felületen azt mutatta, hogy nincs frissítés, a Wsus konzolon pedig azt, hogy van még 24. A Wsus logja szintén 0 frissítést mutatott.

Megtörtént már a SoftwareDistribution törlés, újraindítás, holdfénynél áldozás – a helyzet nem változott. Ekkor hirtelen ötlettől vezérelve megnéztem a Bits állapotát – s íme, egy adott feladat folyamatosan ott szerepelt. Tartományi rendszergazda joggal próbáltam kilőni (a már említett cikkben található utasítással), de nekiállt nyafogni, hogy ő bizony a System nevében fut, én neki nem parancsolok:

GUID: {8B3DBE79-4E5A-4B37-A165-7167EF2FBD63} DISPLAY: ‘WU Client Download’

TYPE: DOWNLOAD STATE: TRANSIENT_ERROR OWNER: NT AUTHORITY\SYSTEM

PRIORITY: HIGH FILES: 0 / 1 BYTES: 0 / 164000

COMPLETION TIME: UNKNOWN ACL FLAGS:

NOTIFY INTERFACE: UNREGISTERED NOTIFICATION FLAGS: 11

RETRY DELAY: 1200 NO PROGRESS TIMEOUT: 1209600 ERROR COUNT: 304

ERROR FILE:    http://Server:8530/Content/akarmi.exe -> C:\Windows\SoftwareDistribution\Download\

ERROR CODE:    0x80070003

ERROR CONTEXT: 0x00000004

DESCRIPTION:

JOB FILES:

0 / 164000 WORKING http://Server:8530/Content/akarmi.exe -> C:\Windows\SoftwareDistribution\Download\

NOTIFICATION COMMAND LINE: none

owner MIC integrity level: SYSTEM

owner elevated ?           true

This job is read-only to the current CMD window because the job’s mandatory integrity level of SYSTEM is higher than the window’s level of HIGH.

Akkor próbáljuk meg a lehetetlent 🙂 Windows 2012 esetén is (mint Vistától kezdve) a legegyszerűbb módja egy System nevében futó parancs-sornak a Sysinternals-tól letölteni a PsExec segédeszközt, majd lefuttatni az alábbi utasítást:

psexec -i -s cmd.exe

Sajnos az így kapott parancs-sorral sem jutottunk előbbre, a kiadott törlési parancs teljesen hatástalan.

Következzen a PowerShell. Futtassuk ezt is a LocalSystem nevében, az előbbi parancs-sorba írjuk be:

%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe

(Az ijedősek megnyugtatására, az útvonallal ellentétben nem az 1.0-s PS fog elindulni :), ennek meggyőződésére a parancs-sorba önmagában begépelve kiírathatjuk a $Host.Version értékét).

Amint a PS betöltődött, kiadjuk a Get-BitsTransfer | Resume-BitsTransfer parancsot – lefut, de nem végzi el a várt műveletet:

Remove-BitsTransfer : The operation being requested was not performed because the user has not logged on to the network. The specified service does not exist.

(Exception from HRESULT: 0x800704DD)

At line:1 char:20

Hm. Tehát valóban nem tudjuk kilőni a SYSTEM nevében futó feladatokat. Akkor ássunk kicsit jobban bele a BITS-be, próbáljuk a kézi műtétet: állítsuk le a BITS szolgáltatást, töröljük a „%ALLUSERSPROFILE%\Application Data\Microsoft\Network\Downloader\qmgr*.dat” állományokat, majd indítsuk újra a letöltésekért felelős programrészt.

Ezzel szerencsésen megszabadultunk a háttérben futó, de hibát generáló letöltésről. Most akkor koncentrálhatunk a többi feladatra.

A lényeg, hogy most végre megjelent ez:

Reporting status event with 24 installable, 13 installed,  0 installed pending, 0 failed and 0 downloaded updates.

De letölteni továbbra sem töltötte le. Akkor nézzük ismét elölről: a WSUS-ban látszik, hogy igény van a foltokra. Látszik, hogy engedélyezett állapotban van. A kliens-gép logjában látszik, hogy ő is telepíthetőnek ítéli meg – de ettől függetlenül „No updates are available” jelenik meg a grafikus felületen, s nem is csinál semmit.

Tipikusan nem látjuk a fától az erdőt jelenség: ugye onnan indultunk ki, hogy leállítottuk a frissítések letöltését (a már említett cikkben). Azóta a Wsus már sikeresen szinkronizált, nem is egyszer, de valamiért a letöltés nem folytatódott – normál esetben a megszakítás utáni első alkalommal már folytatnia kell a letöltést. Itt viszont, ha megnéztük a foltokat, az állományok állapotánál bizony piros x-eket látunk, amelyek csak akkor tűntek el, ha kézzel kiadtuk a letöltés újrapróbálkozására vonatkozó utasítást. Miután ez megtörtént, s a letöltés is befejeződött, máris hajlandó volt magára rántani a foltokat a kérdéses kiszolgáló. Huhh…

BITSAdmin

április 3, 2013 5 hozzászólás

Egy hálózatban kértek meg arra, hogy az addig parlagon heverő Wsus-t állítsam be. Tudjuk, hogy ez nem gond, pár alapbeállítás, aztán mehetünk dolgunkra.

Mivel rész-beállítások már voltak, örömmel vettem tudomásul, hogy a gépek szépen jelentenek a konzolnak, sőt, a frissítések meta-adatai is ott virítanak a képernyőn – magyarul, a rendszerezés, illetve a foltok engedélyezése következik. Első körben engedélyeztem az alap, beépített szabályt, majd lefuttattam (kritikus és biztonsági foltok engedélyezése). Ekkor vettem észre, hogy mekkora hibát követtem el: a Wsus által használt lemezen 10 GB szabad kapacitás volt, a foltok pedig 60 GB-nyi helyet követeltek maguknak.

Megpróbáltam „lelőni” a frissítések letöltését – ez viszont nem ment zökkenőmentesen, a szerver terheltsége miatt a Wsus konzol rendszeresen eldobta magát a frissítések listázásakor. Miután mégiscsak sikerült leállítani a letöltéseket – látszólag –, kiderült, hogy a kezdőképernyőn továbbra is nő a letöltött adatok mennyisége.

Gyors gondolkozás következett. Egyik megoldás lehet egy kamu-kiszolgáló beállítása, ahonnan nem tud letölteni semmit. Egy másik, drasztikusabb megoldás lehet az Update services és BITS szolgáltatások leállítása, a WsusContent tartalmának törlése, majd az említett szolgáltatások újraindítása után kiadott

C:\Program Files\Update Services\Tools\WSUSUtil.exe RESET

utasítás. Ekkor a Wsus ellenőrzi az adatbázisban található frissítéseket, hogy jelen vannak-e a WsusContent könyvtárban a hozzájuk tartozó szükséges állományok. Amennyiben nincsenek ott, egy BITS jobot hoz létre, ami letölti a hiányzó adatokat. Ennek előfeltétele természetesen az, hogy az elmaradt frissítésekről eltávolítom a telepítésre engedélyezett státuszt.

Így elérkeztünk a mélyebb infóhoz. Mielőtt még műtenénk, kérdezzünk már rá a jelenleg is futó letöltésekre. Tudjuk, hogy nem az Update services tölt le, ő csak átadja a letöltési kérelmet a BITS-nek, onnantól kezdve ő tölti le az állományokat. Az aktív letöltések listázása céljából emelt szintű parancs-sorból futtassuk le:

Bitsadmin /list /allusers /verbose

Ekkor már látszott, hogy valóban vannak futó folyamatok. Vagy megkeressük, hogy melyek kötődnek a Wsus-hoz, vagy (esetünkben) ki lehet lőni az összeset:

Bitsadmin /reset /allusers

Legrosszabb esetben egy BITS szolgáltatás-újraindítás még szükséges lehet, de most már valószínűleg nem töltünk le adatokat. Ezzel csak elodáztuk ugyan ideiglenesen a problémát, de legalább kaptunk némi haladékot a felmerült helyhiány kiküszöbölésére.

Aki többet akar tudni, ezen az MS cikken találja meg a paramétereket, itt pedig példákat is láthatunk. Windows 2008 R2 / W7 esetén pedig megjelentek a BITS-el kapcsolatos PowerShell utasítások is, így használhatjuk a Get-Help BITS –et is.

Kategóriák:Windows Server, Wsus Címke: ,