Archívum

Archive for the ‘Wsus’ Category

Ú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…

WSUS 10

szeptember 5, 2017 4 hozzászólás

Újra WSUS, ezúttal egy másik környezet, migrálás régi verzióról egy vadiúj Win2016-os rendszerre. A telepítés, beállítások után szépen kezdenek megjelenni a gépek, melyek (utólag kiderült, szerencsére) még nem homogén OS-el rendelkeznek (Win7, 8.1, 10 vegyesen).

Vannak viszont olyan renitens gépek, amelyek megjelennek a listában, de „Not yet riported” státuszban. Mivel nem akartam kapkodni, s volt egyéb dolgom is, hagytam őket ebben az állapotban egy ideig, de pár nap után már kezdtem ferde szemmel nézni rájuk – főleg, hogy a többiek már rég betöltődtek.

Vegyük sorra, mi az, ami közös. Nos, a problémás gépek mindegyike vagy Server2016, vagy W10 1607 (vagy újabb) verzió volt. Mivel minden 2016-os rendszer friss telepítés, ezért értelemszerűen a legújabb – tehát beleesik a fenti szűrőbe. Az egyedüli sikeres Win10-esen 1511-es verzió található – így legalább tudom, hogy nem globálisan a Win10-el van baja. Kézzel kikényszerítve a frissítést, a következő hibaüzenet fogadott:

There were some problems installing updates, but we’ll try again later. If you keep seeing this and want to search the web or contact support for information, this may help: (0x8024401c)

Rászálltam egy renitens gépre, amelyről tudtam, hogy az előző Wsus-nak hála, naprakész. Kipróbáltam a frissítési hiba esetén szokásos trükkjeimet – de nem segítettek.

A jelzett hibakód egyes források szerint timeout-ra utal, tehát a jelzett esetekben a kliensek nem kaptak időben választ (bár gondoltam a Snefi által is említett MS-írásra, hogy esetleg amiatt lenne gond, esetünkben nem ez okozta a galibát).

A neten keresgélve láttam, hogy másoknak is volt ilyen hibájuk, így kipróbáltam azt a javaslatot, hogy a Wsus kiszolgáló IIS-oldalai által használt Application Pool-nak módosítsam néhány értékét:

  • Queue Length: 1000 helyett 25000
  • Limit Interval (minutes): 5 helyett 15
  • “Service Unavailable” Response: HttpLevel helyett TcpLevel
  • Private Memory Limit (KB): akármennyi* helyett 0.

* Oprendszertől függ, hogy itt milyen érték szerepel.

Mivel nem akartam kísérletezni, illetve körbejárni, hogy pontosan melyik tétel is oldotta meg a problémát, miután türelemmel vártam, s végre megjelent az áhított jelentés, lezártnak tekintettem az ügyet. Ez úgyis csak a migrálás egy kis szeletkéje volt…

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

WSUS 3 és .Net 4.x

augusztus 24, 2017 Hozzászólás

Bizonyos okok miatt az a döntés született, hogy egy SBS2011-en legyen újratelepítve a WSUS. Az eltávolítással nem is voltak gondok, de az ismételt telepítés nem akart semmilyen módon összejönni.

Mivel tudom, hogy nem feltétlenül szükséges a CD2 a telepítéshez, elég letölteni a netről a legújabb verziót, így azzal próbálkoztam. Viszont akárhányszor nekifutottam, akár emelt szintű parancs-sorral, akár grafikus felületről, a WSUSSetup egy adott ponton folyamatosan hibát jelzett s rollback-elt:

Error 0x80070643: Végzetes hiba történt a telepítés során. (Igen, egy magyar SBS-ről van szó, mindenki tudja a véleményem a fordításokról 😊 ).

Nem voltam biztos benne, hogy mi okozza a problémát, így megpróbáltam a szóba jöhető hibákat kiküszöbölni: jogosultságot állítani, függőséget megszüntetni (pl. belső adatbázist is eltávolítani), könyvtárakat üríteni (pl. Windows\SysMSI), a hiba továbbra is megmaradt.

Miután már – nem folyamatosan, de – több órám/napom ráment a történetre, úgy döntöttem, visszatérek az alapokhoz, s megpróbálom a termék logja alapján megkeresni a hibát. Mivel a WSUSCa logban található „hiba”-bejegyzés („The certificate you created is expired.”) csak Warning állapotú volt (bár ez az egy sor is megérne egy misét), a WSUSSetupmsi logot vettem górcső alá. Itt a telepítés lépéseit a következő sorok akasztották meg (ezután már a visszagörgetés műveletei olvashatóak):

Note: 1: 1722 2: PERF_COUNTER_INST 3: C:\Program Files\Update Services\Setup\HideConsoleApp.exe 4: C:\Windows\Microsoft.NET\Framework64\v4.7.2053\InstallUtil.exe /LogFile=”C:\Users\user\AppData\Local\Temp\WSUSCa_170818_2143.log” /ShowCallStack /WsusInstall /CategoryMessageFile=”C:\Program Files\Update Services\Common\EventCategories.dll ” “C:\Program Files\Update Services\Setup\bin\Microsoft.UpdateServices.Setup.CustomActions.dll ”

CustomAction PERF_COUNTER_INST returned actual error code -1 (note this may not be 100% accurate if translation happened inside sandbox)

Termék: Windows Server Update Services 3.0 SP2 — Hiba 1722. Probléma lépett fel a Windows Installer csomaggal.

Tehát a .Net keretrendszer segítségével nem tudott egy utasítást végrehajtani. Az mondjuk már korábban feltűnt, hogy az adott kiszolgálón .Net 4.7 van (amiről tudjuk, hogy pl. az Exch még nem támogatja), viszont rákeresve, kiderül, hogy a neten rengeteg panasz van minden esetben, amikor Wsus3-at szeretnének telepíteni bármely .Net 4.x-et tartalmazó gépre

Az általában javasolt megoldás: eltávolítani a .Net 4.x-et, feltenni a Wsus-t, majd (ha szükséges), vissza lehet tenni a keretrendszert… Kipróbáltam, s bevált: nálam is szépen települt a frissítő-kiszolgáló.

Egy dolog viszont nem hagyott nyugodni, s egy kicsit jobban megkapirgáltam a történetet (s ennél van lehetőség még mélyebbre ásni): a telepítő azért hasal el, mert olyan útvonalon keresi a .Net keretrendszer adott .exe állományát, ami nem létezik. Amennyiben átmásoljuk a teljes .Net könyvtárat a logban jelzett útvonalra, máris rengeteg időt s energiát megspórolunk, hiszen nem kell feleslegesen leszedni/feltenni a keretrendszert (+ a frissítéseit) és a telepítés is sikeresen lezajlik.

S hogy a Wsus telepítő honnan veszi/építi a kérdéses útvonalat – ezzel most tényleg nem akartam foglalkozni (a .Net azon logikáját, hogy megszüntették az útvonalban a verziózást, jobban értem).

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

WSUS gondok

május 25, 2016 Hozzászólás

Az utóbbi időben elég sok 2012/2012 R2 oprendszeren futó WSUS-t kezelő rendszergazdának volt fejfájása. Az ok az, hogy kijött a KB3148812 frissítés, majd nem sok időre rá kijött a javítása, a KB3159706, s mindkét folt telepítése után a konzol használhatatlan lett; így első reakcióként (kerülőmegoldásként) a folt eltávolítása jött szóba. Az, hogy a folt telepítése után fellépő hibák kiküszöbölése érdekében mit kell még tenni, szokatlan módon csak a megjelenés után pár nappal jelent meg.

Nem teljesen szokványos, hogy egy frissítés telepítése után még további reszelést kelljen végrehajtani (bár nem mondhatni azt sem, hogy újdonság, pl. egyes Sharepoint termékek esetén már hagyomány). Ugyanakkor legtöbben azért használunk WSUS-t, hogy részben automatizáljuk a foltok kiszórását, most viszont pont a WSUS működésében lépett fel zavar.

Az elhárításhoz legalább két dolog szükséges:

– megtalálni, hogy mi okozta a hibát (ez nem egyszerű, ugyanis a konzolon a hibaüzenet sem segít, eseménynapló pedig teljesen már irányba visz el minket)

– ha kiderült, hogy a KB3159706, akkor azt elolvasva végrehajtani az ott leírt lépéseket.

S hogy miről is szól ez a folt, miért nem kihagyható? Nos, a Wsus-ban „Upgrades” kategóriába sorolt Windows 10 fejlesztések a Windows Update kiszolgálókon találhatóak titkosított formában már napokkal az élesítés előtt (annak biztosítása érdekében, hogy mindenhol egyszerre tudják kiengedni őket). A Windows 10 oprendszer fel tudja oldani a titkosítást (RTM óta), de a Wsus nem, ezért eddig a Wsus-ra való kiengedés előtt ezeket manuálisan kellett kikódolni, ami időigényes (és lehetséges hibaforrás) volt. A folt felvértezi a 2012/R2-t a kódolás feloldására (2016 már natívan támogatja), ami alapkövetelménye a Windows 10 Anniversary Update (és az őt követő) frissítések kiszórására.

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

Windows 2012 Maintenance window

augusztus 2, 2013 Hozzászólás

Adott helyen abban kérték a segítségem, hogy a többi kiszolgáló mellé telepített Windows 2012 folt-telepítési kezelését megértsék.

Amit tudni érdemes, az, hogy a Microsoft-nál az egész folt-kezelést kissé átalakították (pár szóban itt). Az átalakított verzió lehet, hogy hasznos és bevált a Win8 esetén, de a kiszolgáló-oldalon érdemes lett volna több szabadságot, beállítási lehetőséget hagyni a rendszergazdáknak. Eddig azt lehetett beállítani, hogy adott időpontban (minden nap vagy hét adott napján !!!) hogyan kezelje a gép (vagy a kezelő) a foltokat, most ez a következő módon néz ki: van egy un. Karbantartási ablak (kötelező módon minden nap !!!), ennek keretén belül történik meg a foltok telepítése (és még más is…). Ennek beállítása házirendből itt:

Computer Configuration -> Administrative Templates -> Windows Components -> Maintenance Scheduler -> Maintenance Activation Boundary

Ha a folt olyan jellegű, akkor kapunk egy értesítést, hogy újra kell indítani a számítógépet három napon belül. Ha az újraindítás nem történik meg három napon belül, a számítógép megjelenít egy 15 perces visszaszámlálást, majd automatikusan újraindul. Ha viszont a számítógép zárolva van, akkor alapértelmezés szerint ez a visszaszámlálás akkor kezdődik, amikor legközelebb bejelentkezünk a számítógépre (akkor is, ha ez 3 nap után történik meg).

A zárolás problémájának kezelésére adták ki a KB2835627 foltot, ami annyiban módosítja az eredeti felállást, hogy ha a folt telepítése után a registry-értéket 1-re módosítjuk, akkor a számítógép zárolt állapota esetén is 3 nap eltelte után elkezd automatikusan visszaszámolni, valamint újraindítja a gépet.

Több probléma is van ezzel a váltással. Egyrészt, ha csak Windows 2012 kiszolgálókat üzemeltetünk, akkor minden olyan kiszolgáló, amelyiken engedélyezve van a frissítés (s miért ne lenne?) naponta letölti és telepíti a foltokat. S ha telepíti, akkor felléphet újraindítási igény is – ami még abban az esetben is bajos lehet, ha időben elcsúsztatva frissítjük őket. Kerülőmegoldás lehet, hogy a frissítéseket kezelő kiszolgálón (pl. Wsus) nem egyszerre engedjük ki a foltokat a különböző kiszolgálókra – de ez újabb adminisztrációs feladatot eredményezhet.

Egy másik probléma – s most konkrétan ez merült fel – az automatikus újraindítás. Egy dologra ugyanis érdemes figyelni: ha a folt telepítése után, 3 napon belül bejelentkezünk, egyből megkapjuk a figyelmeztető ablakot, valamint leállíthatatlanul a 15 perces visszaszámlálást (megj: ez abban az esetben, ha a későbbiekben említett (B) beállítás érvényesül). Ha ez pont napközben van, s kritikus minősítésű a kiszolgáló – nos, ez őt akkor sem érdekli, ördögi vigyorral újraindít, ezzel ránk haragítva a teljes felhasználói csapatot, beleértve a top managereket is…

Hivatalos állásfoglalás/kerülőmegoldás az első hivatkozásban található. Annak alapján a telepítési határidő (deadline) jöhet számunkra segítségül – azaz mostantól még erre is figyeljünk… Hogy lesz-e más megoldás, nem tudni, de az igény mindenesetre megvan rá.

Ami bosszantó, hogy ha létező hálózatba illesztjük, akkor is át kell alakítani a frissítési szokásokat – de legalábbis az adminisztrációját mindenképp. Ugyanis az eddig hálózatba kötött kiszolgálókra házirendből volt/van kiküldve az a beállítás, amely szerint (A) telepítés után induljon újra, valamint, hogy (B) hagyja figyelmen kívül a bejelentkezett felhasználókat. Windows 2012 esetén új házirendeket kell készíteni, amelyben (A)-nak nincs helye, (B)-t másképp kell állítani, illetve (C) a karbantartási ablakot kell szabályozni…

Viszont ha továbbra is azt szeretnénk, hogy a Win2012 adott időpontban töltse le a foltokat, telepítse, majd induljon újra (attól függetlenül, hogy van-e bárki bejelentkezve), akkor „hagyományos” módon nem tudjuk elérni, valamivel mindenképp trükközni kell. „Szerencsére” az ügyfél nincs egyedül ezzel a problémájával, több megoldás is található a neten. A vázolt lehetőségek közül számára az tűnt a legszimpatikusabbnak, hogy a kérdéses gép egy ütemezett feladatot indít naponta, amely ellenőrzi, hogy a gép újra kell-e induljon (mármint frissítések miatt 🙂 ), s amennyiben igen, úgy meg is teszi:

reg query “HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update” | find “RebootRequired”

if not errorlevel 1 shutdown /r /t 10

A feladat ütemezésére szintén érdemes figyelni, hiszen ha túl korán futtatjuk, akkor esetleg még nem fejeződött be az összes frissítés telepítése, ha túl későn, akkor kifuthatunk a magunknak szabott karbantartási ablakból.

Kíváncsi vagyok, lesz-e más megoldás a felvetésekre…

Kategóriák:Windows 8, Windows Server, Wsus

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: ,