Vegyük figyelembe azonban a következő mellékhatásokat:

1. Ez a lehetőség csak a Windows XP-vel érkező system.adm sablonban található meg.
2. Per-user házirend elemről van szó.
3. Ez a házirend elem megtiltja a webes Windows Update-hez való hozzáférést.
4. Ha nem 4-es az előző ábrán látható opció, akkor a nem rendszergazda felhasználó sohasem kap értesítést a frissítés letölthetőségéről vagy telepíthetőségéről, ergo frissíteni sem tud.
5. Ha 4-es, akkor sem fenékig tejfel az élet, mivel ekkor letöltődik és települ a frissítés, de az újraindítás elhalasztásába nem tud beleszólni a felhasználó (felugrik a panel, de az elhalasztás szürke lesz), ezért a beállított időérték alapján mindenképpen megtörténik.

A felhasználó bekattintotta a "Hide this update" négyzetet, sőt az újrafigyelmeztetésről szólót is. Mit lehet ekkor csinálni? Hol van ez az információ eltárolva?

A furmányos felhasználó próbálkozik

Egy datastore.edb nevű állományban van eltárolva (%windir%SoftwareDistributionDataStore). Ebben - frissítésenként külön-külön - különböző jellemzők vannak, azaz például, hogy alkalmazható-e, letölthető-e, telepíthető-e, stb., az adott gépen. A rejtetté tett frissítések "reszetelése" ennek az állománynak a törlésével történhet meg. Ehhez állítsuk meg az Automatic Updates szolgáltatást pl. a "net stop wuauserv" paranccsal, majd töröljünk az állományt és indítsuk el újra a szervizt. Ez így szépen működik is, ellenben egy kis szépséghiba ezzel is van, ti. ha elsétálunk a Windows Update oldalon belül a "View History" oldalra, akkor azt üresnek fogjuk látni, mivel ebből az állományból szedi az információt a WU oldal. De - szerintem - ez legyen a legnagyobb baj.

Persze mondhatnánk azt is, hogy ott a deadline, azaz többször említett határidő. Jól is tippelnénk, mivel ez technika tényleg figyelmen kívül hagyja az elrejtést. De - és ezzel a ténnyel már adós voltam - van egy komoly hibája ennek a módszernek. Ugyanis ha határidőt szabunk meg, akkor az újraindítás elhalasztására szolgáló házirend opció (NoAutoReboot) ignorálódik. Renitens felhasználók számára ideális büntetőeszköz lehetne ez a megoldás, de ez azért nem mindig egyszerűen kivitelezhető.

Természetesen az előző kérdésnél említett Csoportházirend opció ("Remove access to use all Windows Update features") is szóba jöhet, de a hátrányaival ugyanúgy számolnunk kell.

Mi az a replika mód, és hogyan lehetséges átállítani egy telepített WSUS szervert ebbe az üzemmódba?

Ha egy WSUS szervert replika módban futtatunk, akkor megörökli a felette levő WSUS kiszolgálótól a konfiguráció elemeit. Tipikusan ilyenkor egy darab olyan WSUS szerver van, amelyet rendszeresen kezelünk és több "gyerek" WSUS, amelyek száma és földrajzi helyzete függ a szervezet felépítésétől és például a topológiájától is. A fő WSUS-on hagyjuk jóvá a frissítéseket és hozzuk létre pl. az egyedi számítógép csoportokat, míg a "gyerek" WSUS-ok tükrözik ezeket a beállításokat.

A WSUS-ban jelen pillanatban nincs semmilyen látható vagy rejtett lehetőség arra, hogy telepítés után replika szerverré alakítsuk (a replikát ne keverjük a szinkronizálással, amelyet az Options Synchronization Options Update Source szakaszban bármikor képesek vagyunk beállítani). Ergo, ha szükséges, okosan előre meg kell terveznünk a WSUS hierarchiát, vagy utólag sok bosszúság jár vele. Vagy itt, vagy sehol

Mi az a Windows Server Update Services Updates?

Ezek azok a frissítések, amelyek nélkül a kliensek nem lesznek képesek tökéletesen együttműködni, főképp a detektálás folyamatában a WSUS-sal. Per pillanat ezek a következőek: a Windows Installer 3.1 és a Background Intelligent Transfer 2.0 (MSI 3.1 & BITS 2.0). Kiemelt szerepüket akkor is megfigyelhetjük, ha egy teljesen szűz gépet helyezünk a WSUS hatása alá, ti. első körben ezt a két frissítést automatikusan letölti az AU kliens, majd a kötelező telepítés (és újraindítás után) jöhet csak az összes többi.