Archívum

Szerzői archívum

Néhány aktivációs eszköz

február 20, 2018 Hozzászólás

Aki nem ma született bárány az informatikában, az valószínűleg belefutott már aktivációs problémákba.

Egyrészt van ugye a grafikus felület, ami egy ideje a System-ből átkerült a fogaskerék Settings alá, az Update & Security/Activation alá. Nos, ez nem mindig akar megfelelően reagálni a kiadott kattintásokra – de sebaj, van más módszerünk is.

Ugyanez a grafikus felület “kattintós” módszer nélkül is előhívható, parancssori eszköze a SLUI (Software Licensing User Interface rövidítése) utasítás, amit egy szám követ (W7-nél újabb rendszerek esetén az első kettő nem játszik).

  • SLUI 1: az aktiválás állapotát jelző ablak nyílik meg

  • SLUI 2: az aktiválást indító ablak nyílik meg

  • SLUI 3: a termékkulcs változtatását teszi lehetővé

  • SLUI 4: kézi aktiválás ablaka (telefonhívással)

Természetesen ne felejtsük el a “céleszközt” (részletesebben itt):

slmgr.vbs /ipk 12345-67890-12345-67890-12345

Végül, de nem utolsó sorban:

Dism /online /Set-Edition: <edition name> /AcceptEula /ProductKey:12345-67890-12345-67890-12345

Reklámok

Hibernálási gondok laptopon

január 23, 2018 Hozzászólás

Adott helyen felmerült, hogy egy hordozható gépen be van állítva, hogy a képernyő lehajtásakor hibernálódjon, ettől függetlenül nem történik meg.

Természetesen powercfg /requests ellenőrzés mindent rendben mutatott. Ellenőrizve lett, hogy a gyártó saját energia-gazdálkodási programja nincs telepítve vagy nem annak a sablonja aktív (ellenkező esetben annak beállításait is érdemes tételesen átnézni, azok elsőbbséget élveznek a rangsorban). A Vezérlőpult/Energia-gazdálkodás esetén a baloldali menüben található opciót kiválasztva látszott, hogy a beállítás elvileg jó:

Ideiglenes megoldásként a hibernálás opciója bekerült a Start menü/Leállítás opciók közé (előző képen szintén látható), de hosszú távú megoldásra is kértek segítséget.

A végleges megoldás a megfelelő energia-használati sablon módosítása volt (itt még az eredeti, rossz értékek láthatóak):

Ezután nézzük, hogy miért is van ez így.

Nos, a megoldást ezt az MS cikk szolgáltatja.

Ennek alapján a “kinti” opciók a “preferált” energia-séma beállításait mutatják, ami természetesen nem mindig az aktív – de hogy miért nem lehet egy mozdulattal azt is állítani, amikor sémát váltunk, nem igazán értem… (feature, nem bug 😉)

A preferált sémát itt találjuk, a PreferredPlan értékben: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\explorer\ControlPanel\NameSpace\{025A5937-A6BE-4686-A844-36FE4BEC8B6D}

Szerencsére ezt meg tudjuk változtatni, ide be kell írjuk a kívánt értéket. Fontos, hogy minden séma-módosítást ezután végezzünk, ugyanis az aktuális séma értékeit fogja oda bemásolni. Ha netalán egyedi sémát hoztunk létre, annak azonosítóját a Powercfg /list lekérdezéssel tudjuk kilistázni – de mint a cikk is említi, a grafikus felületen a “Javasolt” mindig a Balanced mód lesz. 😊

Utolsó hibaként még az merült fel, hogy a jó beállítások végrehajtása után is el szokta “felejteni” a gép a helyes értéket (preferált séma maradt, csak a hibernálás váltott vissza “semmire”). Nos, szerencsére nem tartott sokáig ez az állapot, a gépet naprakész állapotba hozva a frissítés ezt is helyretette.

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

Facebook vs én

december 19, 2017 Hozzászólás

Ez nem egy szakmai cikk lesz, csak egy szolgálati közlemény – GoTo EOF*

Már régóta dübörgött a Facebook-láz, amikor felmerült, hogy én is csatlakozzak a közösségi hálóhoz. Ebben szerepet játszott az is, hogy az ismerősök, rokonok különböző FB-vel kapcsolatos kérdéssel bombáztak (informatikus vagyok, tehát mindenhez értek, nemde? 😊 ) Az alapokat józan paraszti ésszel meg tudtam válaszolni, de néhány kérdés nem volt teljesen világos (pl. valakit ismerősnek jelölni vs valakit követni).

A csatlakozás során természetesen a nick-nevemet használtam, hiszen kizárólag szakmai okok vezéreltek. Ha már csatlakoztam, akkor viszont megjelentettem a blogomra kikerülő cikkekre történő hivatkozásokat is, csak néha jelent meg egy-két más jellegű bejegyzés. Később szakmai csoportokhoz is csatlakoztam (szerintem leginkább az ITMP fog hiányozni), de attól még próbáltam a függőséget elkerülni.

Nos, az eddigi korszak kerül lezárásra, ugyanis elért engem is a FB-pallos. Olvastam eddig is szakmai hírekben, hogy egyesektől személyi igazolványt (vagy egyenértékű hivatalos okiratot) kérnek a személyazonosság igazolására, de arra számítottam, hogy mindezt ésszel teszik (én kis naív 😊 ). Szinte biztos, hogy nem fogják elfogadni az i.e. 50 körüli igazolványom 😊

Szerencsére eddig is sikerült kivonnom magam a FB-bűvölet hatása alól, így nem lesz túlzottan nehéz a szívem… De az is lehet, hogy fiatalodom – hiszen körükben lassan ciki a Facebook 😉 A blogom – csakúgy, mint eddig – továbbra is elérhető RSS-el, emailes feliratkozással, illetve különböző szakmai portálokon keresztül. Aki meg személyesen akar kapcsolatot, az úgyis LinkedIn-en megtalál – vagy a többi, hagyományos módon.

:EOF

Egyszóval, elnézést azoktól, akik eddig Facebook-on követtek, ezután a fent leírt módszerek közül válasszanak. Pont.

*: A Goto EOF és Goto :EOF közötti különbség ismeretében 😊

 

Kategóriák:Uncategorized

Ismét Win10 RS3

december 4, 2017 2 hozzászólás

Nem gondoltam volna, hogy ilyen hamar sor kerül az előző cikk folytatására… Igaz, hogy az utolsó gondolatokban említettem a VLan-ozás problémáját, de azt nem sejtettem, hogy milyen bug-ot feature-t építenek a kollégák ebbe az őszi frissítésbe.

Kezdjük azzal, hogy ha valaki szeretne VLan-t használni a Win10-en, akkor switch-független megoldásként két fő lehetősége van: vagy használja a hálókártya gyártójának saját programját (ha van), ami le tudja kezelni a vlan-tageket, vagy feltelepíti a Hyper-V komponenst, létrehoz egy External típusú virtuális switchet, amibe beteszi a pipát és a VLan-azonosítót. Előbbivel az a gond, hogy vagy van ilyen program, vagy nincs; ha nem egységes a hálózat, akkor esetenként különböző programokat kell használni; esetleg a program nem kompatibilis valamilyen más programmal. Utóbbi esetén hátrány lehet, hogy fent van a virtualizációs komponens (további réteg meg biztonsági megfontolások, ugyebár), illetve ennek előzménye a megfelelő hardver (no igen, soha senki nem vesz virtualizációt nem tudó gépet, mert olyan khm… nem is létezik).

No de visszatérve a fő csapásra. Adva vannak a gépek, szépen beállítva, mindegyiken ott figyel a Vlan. Erre jön az őszi frissítés, ami szépen csili-vili gépet varázsol az ócskaságból – egy apró hibával. A jól beállított, Vlan-al rendelkező virtuális switch-ből eltünteti a VLan taget és a Vlan-kapcsoló pipát, ráadásul úgy, hogy szürkévé teszi a bekapcsolás lehetőségét. Nem akartam nagyon a mélyére ásni, hogy ezt milyen megfontolásból, inkább a probléma megszüntetése volt előtérben.

Első körben természetesen a legegyszerűbb megoldás jutott eszembe: törölni a virtuális kapcsolót, s újat létrehozni megfelelő beállításokkal. Igen ám, de az új létrehozásakor mindenféle hibát dobott ki, mely szerint valamit nem talál, nincs ilyen, stb. Eseménynaplót ellenőrizve kiderül, hogy a hálózati kártya azonosítójával van baja, azt nem tudja megemészteni. A kártya letiltása, engedélyezése nem segít, egyedül az oldotta meg számomra a problémát, ha a kártyát eltávolítottam (driver maradhat), illetve ismét felismertettem vele – ezután már csont nélkül létre lehetett hozni a kapcsolót.

Ha belegondolok, hogy egy nagyobb cég esetén ezt tömegesen kell(ene) elvégezni, csak azt tudom mondani, hogy kösz MS.

Hyper-V: Default switch

november 20, 2017 2 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 😊

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