Archívum

Archive for the ‘General’ Category

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

RDP tanúsítvány

május 24, 2017 Hozzászólás

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.

Házirendek csak hordozható gépekre

március 20, 2017 1 hozzászólás

Adott helyen felmerült a kérdés, hogy miként lehet úgy kiszórni egy házirendet, hogy csak a hordozható eszközökre legyen érvényes.

Egyrészt természetesen maradhat a jól bevált módszer, amely szerint AD-csoportot hozunk létre, s csak arra érvényesítjük a házirendet (vagy fordítva, abba tesszük azokat a gépeket, amelyekre nem kell érvényesüljön, s „Apply group policy – Deny” opciót választunk). Ugyanakkor létezik „elegánsabb” módszer is, WMI-szűrő segítségével.

Nem fogok felsorolni minden lehetséges szűrést, ami alapján kétfelé tudjuk választani a gépeink, néhány ötletet adok csak:

1. a memória fizikai mérete alapján: tudjuk, hogy a hordozható eszközökbe SODIMM memória kerül, asztali társaikba pedig „normál” méretű DIMM. Előbbinek FormFactor értéke 12, így a szűrönk így néz ki:

Select * from Win32_PhysicalMemory WHERE (FormFactor = 12)

2. az akkumulátor jelenléte alapján (ha nincs, akkor értéke 0; bár mivel van, aki akku nélkül használja, fenntartással kezelném):

Select * from Win32_Battery WHERE (BatteryStatus <> 0)

3. ha tudjuk, hogy minden DMI adat ki van töltve (személy szerint igyekszem erre mindig figyelni), akkor a ház típusa (burkolat) alapján is lehet szűrni, az általában használt értékek itt vannak felsorolva (ebben az esetben természetesen granulárisabban tudunk szűrni):

Select * From Win32_SystemEnclosure Where ChassisTypes = “9”

p.s. régi kapcsolatommal, Tamással [Aida64 vezető fejlesztője] történt egyeztetésem kapcsán felmerült, hogy most már sok alaplap – főleg a Mini-ITX és Mini-STX kialakításúak –, valamint sok mini-PC is SO-DIMM foglalatos, így az első nem biztos, hogy teljes értékű megoldás. Viszont akinek a hálózatában ilyenek vannak, használhatja a többi (akár általam le nem írt) módszert 🙂

Hibakód szöveges értelmezése egy Win2016 ütemezett feladat kapcsán

február 1, 2017 3 hozzászólás

Többször szokták tőlem kérdezni (tanfolyamokon is), hogy mi a legegyszerűbb módja egy hibakód „visszafejtésének”, azaz a hozzá tartozó szöveges hibaüzenet kiderítésének. S itt természetesen nem a „well-known” kódokról beszélek (pl. 0x80070005 Access denied) :).

Mivel kétféle módon jelenhetnek meg a hibakódok, kezdem a decimális formátummal (előtagja 0n) – ugyanis első lépésben úgyis hexává (előtagja 0x, a másik formátum) alakítjuk, s innentől már ugyanaz a menet. Tehát mit kell tudnunk, ha mondjuk egy 2147944189 számú hibaüzenetet meglátunk?

A megoldáshoz vegyünk elő egy számológépet, ami tudja a két számrendszert (Windows-on a számológépet pl. „Programozó” módba kell állítani). Kiválasztjuk a hibakód számrendszerét (decimális vagy hexadecimális), beírjuk az ismert értéket, majd megnézzük azt hexadecimális formában. Amennyiben az első négy karakter „8007”, akkor rendben vagyunk, ú.n. „Win32 Status Code” lesz a megfejtés, innentől csak a második négy karakter lesz érdekes.

Következő lépésként a második négy karaktert kell visszalakítsuk decimálissá. Ehhez a számológépbe beírjuk hexa formátumban, majd kiolvassuk decimálisban. Utolsó lépésként lefuttatjuk az alábbi parancsot, s meg is van a keresett szöveges hibaüzenet:

net helpmsg decimális_szám

Mivel az operációs rendszer nyelvén kapjuk vissza az üzenetet, a honosítások nem biztos, hogy visszaadják az eredeti értelmezést, így javaslatom szerint ezt mindenképp egy angol nyelvű gépen tegyük meg (utána könnyebb rákeresni is) – s reménykedünk benne, hogy nem visz tévútra.

S hogy miért pont ezt a konkrét hibakódot hoztam fel? Egy számomra eddig ismeretlen jelenség miatt: egy Windows 2016-on szerettem volna ütemezett feladatot beállítani, hogy egy technikai felhasználó nevében fusson – s ekkor örvendeztetett meg a rendszer a fenti kóddal. A felhasználónak volt elég joga, nem volt letiltva, nem volt zárolva – az egyedüli „hibája” az volt, hogy azon a gépen nem volt profilja (hiszen soha nem lépett be rajta). Az eddigi Windows-okon ez nem volt gond, legelső futtatásnál létrejött a profil – itt az idő szűkössége miatt leggyorsabb megoldás az volt, hogy bejelentkeztem a fiókkal, utána már csont nélkül elfogadta az ütemezett feladat hozzárendelését is.

Windows 10 és Network Level Authentication

október 1, 2016 14 hozzászólás

Bár úgy rémlik, hogy régebben már írtam az NLA-ról (s most nem a Network Location Awareness-ről beszélek 🙂 ), hirtelen nem találtam meg a cikket. Ez a Windows Vista/2008-tól bevezetett lehetőség azt a célt szolgálja, hogy legalább RDP 6.0 protokollt használó kliensek esetén még a munkamenet létrehozása előtt bekérje a hitelesítő adatokat. Az oka egyszerű: elrejti a szerver/hálózat adatait, így növelve a biztonságot. Régebbi (nem NLA-képes) kliensek esetén az alábbi hibaüzenet fogad:

„The remote computer requires authentication for you to connect. Verify the authentication settings and try again.”

networklevelauth

Nos, alapból a Win10 (is) úgy érkezik, hogy a Távoli asztal engedélyezésekor az NLA be van kapcsolva. Ebben nem lenne semmilyen hiba, de sajnos a grafikus felületre kivezetett pipa nem segít, annak eltávolítása után sem tudunk régebbi RDP-kliensekkel csatlakozni. Ezt a bug-ot feature-t szerencsére registry-módosítással fel tudjuk oldani:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

kulcsban kell a SecurityLayer értéket 0-ra állítani.

Frissítés: Bár most csak TP5-el tudtam kipróbálni, valószínűleg a Win2016 RTM-ben is ugyanez a helyzet.

Frissítés2: Némi pontosítással élnék. Amíg a grafikus felületre kivezetett pipa nincs eltávolítva, addig időtúllépésre fut a kérés:

networklevelauth2

Tehát előbb azt ki kell kapcsoljuk, majd utána registry-t is módosítsuk (sorrend fontos!), s utána lehetséges csatlakozni.

Alvó szerver

április 21, 2016 2 hozzászólás

Egy „legendás” „piros gombos” segítségkérés során az volt a kérdés, hogy egy Windows 2012 R2 kiszolgáló miért elérhetetlen időnként. Ráadásul egy olyan környezetben, ahol 1 kiszolgáló van, a felhasználók száma is minimális, és látszólag semmi nem indokolja a szerver leállását.

A hibakeresés szerencsére aránylag hamar feltárta az okot, az eseménynapló rengeteget segített, a System-ben ez volt:

Kernel-power 42

The system is entering sleep.

Sleep Reason: Application API

Nos, nem gyakori, hogy egy szervert elküldenek aludni. Ha meg igen, akkor lehet, hogy célszerűbb inkább leállítani, majd amikor szükséges, akkor újból indítani, nulláról betölteni – de jellemzően nem ekkora cégről beszélünk ilyen esetekben, hiszen az „ébresztéshez” valószínűleg egy másik kiszolgálót használunk. No meg, 1 kiszolgáló esetén önmaga a DC is, amit meg tényleg nincs miért leállítani – s még lehetne sorolni a különböző érveket.

No de menjünk tovább, nézzük az Application naplót a kérdéses időpontokban – hiszen ő is arra hivatkozik, hogy egy alkalmazás állította le, reméljük olyan, amelyik készít naplózást. Máris két bejegyzés kerül elénk, egy hiba meg egy információs fokozatú (idő szerinti sorrendben):

APC UPS Service 61503:

Internal Communication Fault with your battery backup.

APC UPS Service 177:

PowerChute causing PC to hibernate.

Ez már egy nyom, amin el lehet indulni. Tehát valamiért megszakadt a kapcsolat a szünetmentessel, emiatt pedig az alkalmazás kiadta a hibernálási utasítást. Eleve rossz gondolatnak tartom, hogy egy kapcsolat-szakadás miatt ilyen döntést hozzon az alkalmazás, de sajnos az alkalmazás beállításainál nincs erre vonatkozó szabályozási lehetőség.

Rendben, feltártuk a hibát, nézzük, milyen lehetőségünk van a megszüntetésre. Mivel az alkalmazás verziója a legfrissebb, s nincs benne erre vonatkozó állítás, a szünetmentes USB-n keresztül csatlakozik a kiszolgálóhoz, sok esélyünk nincs, így a gyártóhoz fordultam.

A gyártóval történt levelezgetés után kiderült, hogy hol történt az elhibázott döntés:

„A PCBE csak SMART UPS termékekkel működik.

A PCPE csak BACK UPS termékekkel működik.

A Windows 2012  operációs rendszerrel nem fog működni csak a PCBE; ebben az esetben egy SMART UPS-re van szüksége.”

Tekintettel arra, hogy az UPS vásárlásakor egy XP volt „a szerver”, s a „kolléga” nem gondolkozott elég éretten (vagy anyagi megfontolásból), egy olyan terméket vásároltak, amelyik nem kiszolgáló-oldali célfelhasználásra van kitalálva (mondjuk jó pont, hogy egyáltalán gondolt szünetmentesre). Emiatt a szerverre is csak a PCPE telepítése során lehetett az eszközzel felvenni a kapcsolatot, ami „nagy vonalakban” jól működik – de „apróbb” hibák előfordulnak. Pl, hogy időnként hibernálja a szervert. Random időpontokban.

p.s. Nemrég kaptam a képet, hogy ha letiltásra kerül a hibernálás a kiszolgálón (milyen eretnek gondolat, brr…), akkor a program panaszkodik:

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