Hyper-V: Default switch

november 20, 2017 1 hozzászólás

Aki már váltott a Windows 10 1709-es verziójára, s netalán telepítve volt (vagy utólag telepíti) a Hyper-V komponens(t), meglepődve tapasztalhatja, hogy alapból létrejön egy „Default switch” nevű virtuális kapcsoló, aminek alapbeállításain nem tudunk módosítani, sőt, eltávolítani sem tudjuk. Ennek kapcsán felmerült néhány gondolatom, a teljesség igénye nélkül.

Bár történetét tekintve állítólag ez a kapcsoló egy régi felhasználói kérés, bizonyos szempontból nem igazán nyerte el a tetszésem. De mielőtt elmondanám a gondjaim, lássuk, milyen célt is szolgál:
– a hozzá csatlakoztatott gépek NAT-on keresztül kilátnak a hálózatra, elvileg attól függetlenül, hogy vezetékesen vagy vezeték nélkül csatlakozik a gazda-gép
– minden Win10 gépen azonos azonosítóval (GUID) rendelkezik, így a VM-ek mozgatása ezek között nem okoz fejfájást (eddig külön szoktunk erre figyelni)

Ez szép és jó, de miért nem tetszik? Nos, egyrészt kezdjük azzal, hogy mindenki kap a gazdagépen egy újabb hálózati csatlakozót (természetesen azokra gondolok, akiknek telepítve van a Hyper-V komponens). Egy olyan környezetben, ahol eleve van több csatlakozó (fizikai vagy virtuális), még egy további megjelenése megosztott figyelmet igényel. Ez elkerülhető lett volna azzal, hogy akinek nem tetszik, az távolíthassa el. Természetesen meg lehet próbálni kikapcsolni rajta a különböző protokollokat és szolgáltatásokat (ipv4, Client for MS Networks, …), de ez csak egy ideig megoldás, hiszen a Windows automatikusan helyreállítja a kapcsoló állapotát.

Egy másik gondomat oktatóként közelítem meg. Eddig a Hyper-V oktatásokon megmutattuk, hogy miként lehet beállítani a kapcsolókat, melyiket milyen célra használjuk, de az emberek lustasága (persze, tudom, lusta ember nincs is…) abba az irányba fogja terelni a többséget, hogy a VM-nek adjuk oda az „alapértelmezett” kapcsolót, s kész. Lesz internet, lesz minden, mehetünk szórakozni. Mondjuk akiket valóban érdekel a téma, azok szinte biztos, hogy belemélyednek majd, s létrehozzák a „hagyományos” kapcsolókat, de lehet, hogy ők akkor az előző pontba futnak majd bele: el szeretnék távolítani ez az új kapcsolót – sikertelenül.

További problémaként (s itt ismét szeretném kihangsúlyozni, hogy nem teljes körűen megvilágítva) a biztonságosságot vetném fel. A VM-ek gépek közötti mozgatásánál oda kellett figyelni, hogy melyiken milyen kapcsolók vannak – ezzel ez kikerülhető. Sőt, ha elképzelem azt, hogy egy rosszindulatú programozó majd ír egy olyan kódot, ami egy virtuális gépben (sőt, ne csak hagyományos VM-ben, hanem mondjuk pl. Docker konténerben gondolkozzunk) fut, annak elég megadni a jól ismert kapcsoló GUID-ját (hiszen minden gépen azonos, nyelvtől, időjárástól, stb függetlenül), hogy kilásson az internetre, s „láthatatlanul” küldjön csomagokat – mondjuk egy szaki vélhetően hamar megtalálja, de egy otthoni felhasználó? Igaz, utóbbinak nem kell Hyper-V, de akkor gondoljunk mondjuk egy KKV-ra, ahol nincs profi rendszergazda, de valamiért szükséges a gépeken az említett modul (ismerek konkrét esetet, amikor pl. VLan-ozás miatt kellett telepíteni ezt a virtualizációs komponenst).

Egy szó, mint száz, még nem igazán nyerte el a tetszésemet – s ekkor még finoman, nőiesen fogalmaztam 😊

Reklámok

Biometrikus azonosítás/PIN tipp

október 31, 2017 Hozzászólás

Egy rövid memó: ha a biometrikus azonosítással és PIN-kóddal történő bejelentkezés szürke egy tartományi gépen, akkor a megoldás egyszerű: egy registry-értéket kell létrehozni:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\System]
“AllowDomainPINLogon”=dword:00000001

Kategóriák:Windows 10 Címke:

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\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).

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

Out-of-office on Distribution Group

július 24, 2017 4 hozzászólás

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 🙂

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

Windows 10 Fall Creators Update vs WannaCry & Petya

június 28, 2017 4 hozzászólás

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

június 7, 2017 Hozzászólás

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.