WSUS 10
Ú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…
WSUS 3 és .Net 4.x
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\voros\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).
Out-of-office on Distribution Group
Még régebben feltettek nekem egy kérdést, amit érdemesnek tartok egy eszmefuttatásra: miként lehet egy disztribúciós csoporton beállítani automatikus választ?
A kolléga eredeti ötlete az volt, hogy a levél-tippet használja fel (felhasználóknál a beállítás Fájl / Beállítások / Levelek / Email tippek szekció). Nos, az Outlook 2010-től használható email-tipp jellemzően* belső címzett esetén jelenik meg, s arra használható, hogy a feladó kiválasztása után, de még a levél elküldése előtt értesüljünk a címzett állapotáról. Pontosabban, ha az illetőnél be van kapcsolva a “Házon/magán kívül” állapot, akkor az ott megadott szöveg lesz látható még a levél elküldése előtt, illetve, ha tagja valamilyen csoportnak, akkor a csoporton beállított MailTip is látszik.
(* bizonyos, jól meghatározott esetekben külső címzett is, pl. érzékeny információ küldésekor).
Az eredeti kérdésre a választ több módon oldhatjuk meg, példaként 1-1 szerver-oldali, illetve fiók-szinten megvalósított ötletet írok, a teljesség/mélység igénye nélkül (no meg 3rd party megoldások kihagyásával).
A Transport Rule estén a szerveren hozunk létre egy szabályt, de annak formátuma (illetve az SMTP-kódja) nagyon hasonló a hibaüzenetekhez, még akkor is, ha saját hibaüzenetet teszünk be (most maradjunk az egyszerű rgazda szinten), ezért ezt – főleg kezdőknek – nem javaslom.
Fiók-oldalon sokkal elegánsabb megoldási lehetőségünk van, erre például egy dedikált fiókot hoznék létre – ő már tud OoO üzenettel válaszolni (ne feledjük, ez feladónként napi 1 üzenetet eredményez), az általa kapott leveleket pedig automatikusan továbbítani a csoportnak (akár úgy, hogy neki lokálisan is maradjon egy példány, naplózási céllal).
Sokan felkaphatják a fejüket, hogy de ők láttak az elosztási csoportokon olyan pipát, ami OoO-val kapcsolatos. Igen, a régebbi Exchange-ken az Advanced fülön grafikusan ki volt vezetve egy ilyen pipalehetőség („Send Out-of-office message to originator”), de ez csak arra való, hogy a tagok bármelyikén beállított OoO üzeneteket az eredeti feladónak küldje, ne a csoportnak szórja szét. Ha ez megfelelőnek tűnik az eredeti probléma megoldására, számítsunk rá, hogy nem biztos, hogy mindenki egységesen állítja be az ilyen üzeneteket, illetve, amennyiben a csoportból többen beállítottak maguknak saját OoO üzenetet, a feladó mindenkitől megkapja.
Az újabb Exchange-ken a grafikus kivezetés helyét a PS vette át:
Get-DistributionGroup * | Set-DistributionGroup -SendOofMessageToOriginatorEnabled:$true
Amennyiben még tovább bonyolítjuk a kérdést, s szeretnénk képet betenni: nos, ezt nem támogatja az OoO. Ha mégsem bírjuk ki, akkor Outlook segítségével létrehozunk egy szabályt, ami egy olyan sablonra mutat, amelyik megfelelően elő van készítve – de ez már tényleg túlmutat a cikk keretein 🙂
Windows 10 Fall Creators Update vs WannaCry & Petya
Aki az IT világában él (sőt, akinek van számítógépe), biztosan tud a múlt havi WannaCry-járványról, ennek ráadásaként tegnap aktiválódott a Petya zsarolóvírus is. Mindkettő az SMB1 protokoll egyik hibáját használja ki, s ennek lassú kihalása okán kapták a már nem támogatott rendszerek is a javítófoltokat.
Ugyanakkor lassan, de biztosan elkezdtek csepegni infók a Win10 idei őszi frissítéséről. Az indító gondolathoz kapcsolódik az egyik friss és fontos információ is, aminek sokan nem fognak örülni: az említett frissítéstől kezdve megszűnik az SMB1, magyarul a Windows 2003 és régebbi rendszerekkel való kapcsolattartási lehetőség.
Tudom, sokan nem értik, hogy miért foglalkozom ilyen ősrégi rendszerekkel. Nos, egyszerűen azért, mert a magyar viszonyokat ismerve, nem egy cégnél található még ilyen oprendszer. Félig haladva a korral, vannak már Win10-es munkaállomások, de a szerver-csere még nem történt meg. Sőt, továbbmegyek, azok a régi nyomtatók/készülékek, melyek csak ezt a régi protokollt ismerik/használják, szintén ki fognak esni a játékból.
Természetesen kell haladni a korral. Hiszen mint említettem, a WannaCry/Petya is erre épül, ennek a sebezhetőségét használta ki. Általános (és kiterjesztett) támogatása is lejárt. Viszont hiába voltak a különböző fórumokon, médiákon elhangzott figyelmeztetések, áttérésre figyelmeztető oktató-videók, felhívások, sajnos továbbra is rengetegen vannak régi rendszerekkel – részben anyagi, részben más okok miatt. Érdemes az ottani rendszergazdáknak/informatikusoknak ismételten jelezni a vezetőség felé, hogy a kockázat folyamatosan nő…
ps. eredetileg egy hosszabb cikknek készült volna, de Petya áthúzta a tervem. Hogy mégse maradjon senki szakmai tartalom nélkül, egy elég jól összeállított MS-cikket linkelek be az SMB protokollokról.
Törölhetetlen OU
Adott helyen egy SBS2011-ről tértek át Windows Server 2012 R2 Foundation-re. A migrálás rendben lezajlott, viszont utána az AD-ban is rendet szerettek volna tenni, magyarul az SBS által létrehozott hierarchiát egyszerűsíteni.
Az útmutatást ekkor váltotta fel a gyakorlati segítségnyújtás: volt két szervezeti egység (OU), amit semmilyen módon nem tudtak törölni (a törlési opció nem is volt felajánlva a helyi menüben): az SBSComputers és SBSUsers. Ellenőrizték, hogy nincs betéve a „törlés-gátló” pipa, de a törlést továbbra sem tudták végrehajtani.
A megoldás megértéséhez kicsit vissza kell menjünk időben. A Windows 2003-ban (és 2003-as tartományi szinttől) jelent meg az a lehetőség, hogy a számítógép- és felhasználó-fiókok alapértelmezett helyét (Computers, illetve Users konténer) meg tudjuk változtatni (RedirCmp, RedirUsr). Az átirányítás során bekapcsolásra kerül a cél szervezeti egységeken az IsCriticalSystemObject attribútum is, ennek TRUE értéke okozza a törölhetetlenséget és az átnevezhetetlenséget. Az SBS ezt előszeretettel alkalmazza, az ominózus OU-kba irányítva a megfelelő fiókokat. (Csak egy apró megjegyzés, ha valaki nem SBS-en hajtja végre: a művelet végrehajtásához a PDC emulátor FSMO-szerepkörű géphez fog fordulni).
Igen ám, de miként tudjuk ellenőrizni, hogy hova is vannak irányítva? Nos, 2003-ban csak az ADSIEdit-el tudtuk megnézni, 2008-tól kezdve az „Advanced Features” bekapcsolásával az ADUC-ban is a tartomány tulajdonságainál, a WellKnownObjects attribútumban. Ez tartalmazza mindkét értéket (sőt, még mást is), számítógépek esetén a B:32:AA31 kezdetű, felhasználók esetén B:32:A9D1 kezdetű hexaérték után.
De már ez is a múlt. Windows Server 2008 R2 óta már Powershell segítségével is lekérdezhető:
Get-ADDomain | select ComputersContainer
Get-ADDomain | select UsersContainer
Amint megszüntettük a lokkolást (máshova irányítottuk), egyből megjelent a törlési lehetőség.
RDP tanúsítvány
Egy régi félkész cikket próbálok befejezni… A témát réges-rég is említettem, minimálisan, de azóta rengeteg víz lefolyt a Dunán 🙂
Nos, akkor kezdjük átismételni, mi történik, amikor RDP-vel csatlakozni próbálunk egy géphez (leírás, értékek). Első körben van egy biztonsági ellenőrzés, amelynek során a rendszer ellenőrzi a registry-ben, hogy van-e már mentett kapcsolatunk a távoli kiszolgálóhoz, s abban mit engedélyeztünk (HKCU\Software\Microsoft\Terminal Server Client\LocalDevices\<Név> – ha csak most engedélyezzük az elsőt, létrehozza a LocalDevices kulcsot is). Ennek fényében kapunk egy sárga, vagy, ha “online” csatlakozunk (nem RDP-állomány), akkor a változatosság kedvéért kék ablakot (hogy még bonyolultabb legyen, a kék ablak sem mindig pattan elénk, csak az 1, 2, 32 értékek hiányában):
A kék ablak (ha nem RDP-állományból, esetleg ha a LocalDevices értéke 12 (1100) – amennyiben betesszük a pipát, akkor az érték 77 (0100 1101) lesz):
Továbbjutva az első akadályon, máris egy másik registry-kulcs által szabályozott területre érünk. Ekkor a rendszer ellenőrzi a HKCU\Software\Microsoft\Terminal Server Client\Servers kulcs tartalmát, s amennyiben van, úgy alapértelmezés szerint felajánlja az itt található UsernameHint felhasználót s kéri a jelszavát. Amennyiben nincs, egy választó-ablakot dob fel, az aktuális felhasználónak kérve a jelszavát vagy lehetőséget adva másik felhasználónév/jelszó megadására. Ha van mentett jelszavunk, akkor természetesen kiolvastathatjuk a Hitelesítőadat-kezelőből is. Sikeres hitelesítés esetén megérkeztünk az aktuális témához, a második sárga ablakhoz:
Ennek megfejtése: szintén az előbb említett registry-kulcsban előfordulhat egy tanúsítvány-kivonat (hash) – ha ez érvényes, azaz megegyezik a gépen tárolt tanúsítvány lenyomatával, észrevétlenül csatlakozunk a kiszolgálóhoz – ellenkező esetben jön elő a jelzett, második sárga ablak. Ha utánajárunk az alapértelmezett, önaláírt tanúsítványnak, kiderül, hogy a számítógép tanúsítvány-tároló Remote Desktop mappájában található, így könnyen gondolhatnánk, hogy azt lecserélve hátradőlhetünk – de ez nem így van. Elkeseredésre azért nincs ok, mert azért a megoldás egyszerű: miután a “jó” tanúsítványt betesszük a számítógép tanúsítvány-tároló Personal mappájába , le kell cseréljük a WMI-ban tárolt tanúsítvány-kivonat értékét (szaknyelven a root\cimv2\TerminalServices névtér Win32_TSGeneralSetting osztály beállításaiban a SSLCertificateSHA1Hash értékét kell cserélni ). Visszalépni nem lehet (de minek is kellene?).
Biztos, ami biztos, előbb lekérdezzük a jelenlegi értéket:
wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Get SSLCertificateSHA1Hash
Ugyanezt az eredményt kell találjuk a grafikus felületen megnyitott tanúsítvány ujjlenyomat-értékében is (“Thumbprint”).
Szintén pl. a grafikus felület segítségével kiderítjük a számítógép “rendes” tanúsítványának lenyomatát, majd a cseréhez a következő utasítást kell végrehajtani:
wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash=”THUMBPRINT”
Vagy aki inkább Powershell-t használna (Set-WmiInstance helyett lehetne swmi, hasonlóan a Get-WmiObject helyett gwmi):
# Lekérdezzük a jelenlegi lenyomatot
$TSGeneralSetting = Get-WmiObject -class “Win32_TSGeneralSetting” -Namespace root\cimv2\terminalservices -Filter “TerminalName=’RDP-tcp'”
# A számítógép tanúsítvány-tárából kiválasztjuk az SSL-tanúsítvány lenyomatát (ha több tanúsítványunk van, akkor ellenőrizzük a kapott eredményt)
$thumb = (gci -path cert:/LocalMachine/My | select -first 1).Thumbprint
# Beállítjuk az új értéket Set-WmiInstance -Path $TSGeneralSetting.__path -argument @{SSLCertificateSHA1Hash=”$thumb”}
Ezt tovább tudjuk fokozni, hogyha más néven csatlakoztunk, további adatok lesznek a sárga ablakon:
Ha viszont egy olyan kiszolgálóra csatlakozunk, amelyik nem támogatja az NLA-t (például alábbi esetben Windows 2003), akkor az alábbi ablakok jönnek:
Huhh, elég volt a sárga ablakokból. Uff.
BitLocker kulcsok házirendben szabályozva
Adott helyen felmerült a házirendből szabályozott BitLocker – pontosabban a visszaállítási kulcsok mentésének módja. Magyarul, nem szeretnénk azt, hogy ha bekapcsolják a titkosítást, akkor USB-kulcsra, állományba vagy nyomtatásra kerüljön a visszaállító kulcs, hanem az AD-t használjuk erre a célra. Ha nem régi rendszerekről van szó, aránylag kevés beállítást kell végrehajtanunk, hogy sikeresek legyünk:
- Computer Configuration\Administrative Templates\System\Trusted Platform Module Services alatt engedélyezzük a Turn on TPM backup to Active Directory Domain Services opciót
- Computer Configuration\Administrative Templates\Windows Components\BitLocker Drive Encryption alatt eldöntjük, hogy melyik ágon megyünk tovább: adatlemezre (beépített vagy eltávolítható) vagy rendszerlemezre szeretnénk alkalmazni a titkosítást. Döntés után a Choose how BitLocker-protected fixed drives can be recovered opcióba lépve, engedélyezve és a benne található lehetőségeket beállítva mondhatni készen is vagyunk.
(Aki Vista/2008 rendszereken szeretné, vagy bővebb információt olvasna, részletesebb leírás itt található).
Van viszont egy kapcsoló, amire szerintem nincs eléggé felhíva a figyelem, s kissé megkavarhatja az egyszerű rendszergazdát. Arról van szó, hogy ha nem pipáljuk be a „Omit recovery options from the BitLocker setup wizard” opciót, akkor a BitLocker bekapcsolásakor feldobja a hagyományos ablakot, hogy hova akarjuk menteni a visszaállító kulcsot – emiatt nem lehetünk biztosak benne, hogy a gép megkapta-e a házirendet (amiben beállítottuk, hogy AD-ba kerüljön). Ezt tehát mindenképp bepipálnám.
Ha kiadtuk a titkosítási parancsot, egy újraindítást fog kérni, majd utána a
manage-bde -status c:
parancs segítségével tudjuk lekérdezni a titkosítás állapotát.
Természetesen, utólag is van lehetőségünk a Control Panel/Bitlocker Drive Encryption menü segítségével a kulcs megszokott mentésére (USB-kulcs, állomány vagy nyomtatás). Amennyiben az AD-ból akarjuk mégis elővarázsolni, két lépést érdemes tennünk: feltelepítjük az RSAT-ból a „BitLocker Password Recovery Viewer”-t, majd a szükséges .dll állományt regisztráljuk:
regsvr32.exe BdeAducExt.dll
A fentiek hatására az ADUC-ban meg fog jelenni egy BitLocker Recovery fül, ami tartalmazni fogja a kívánt kulcsot.
u.i. Figyeljünk arra, hogy amennyiben úgy állítottuk be (ahogy a józan ész diktálja), hogy titkosítás előtt ellenőrizze az AD-kapcsolatot, úgy nem járható út, hogy napközben bekapcsoljuk a titkosítást, de nem indítjuk újra a gépet – ha ugyanis a kolléga leállítja, majd hazaviszi az eszközét, s otthon bekapcsolja, az AD-kapcsolat hiányában nem történik meg a várt művelet. Természetesen következő alkalommal (már AD-kapcsolattal) ismét lehet kérni a BitLocker bekapcsolását, ekkor az új kulcs is bekerül a másik mellé.
