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 🙂

Reklámok

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 Mobile RS1 vs FM rádió

január 10, 2017 2 hozzászólás

Már itt a blogon is többször írtam arról, hogy egy Windows 10 Mobile-os okostelefonnal rendelkezem. Jellemzően elégedett vagyok vele, de mint szakmabeli, látom a korlátokat/hiányosságokat is.

Jelen morgásom arról szól, hogy eddig észre sem vettem, de az RS1-ben kivették a beépített alkalmazások közül a hagyományos FM-rádiót. Nem használom gyakran, de amikor viszont használtam, tetszett az egyszerű kezelhetőség, valamint az, hogy eleve az oprendszer tartalmazza. Aki ismer, tudja, hogy nem szeretem sokmillió programmal terhelni egyik eszközömet sem, ezért mindig adok egy esélyt a beépített alkalmazásoknak (még ha az nem is válik be, pl. asztali gépen az Edge mint PDF-olvasó, vagy az új, előzetes Skype).

Üsse kavics, kivették, az úton már nem volt időm/kedvem vacakolni egy megfelelő alkalmazás kiválasztásával, így későbbre tolódott ez a tevékenység. Amikor viszont nekiálltam keresni, egyrészt a stream-ek kezelésére való alkalmazások jöttek elő (miért hívják őket rádiónak??), másrészt végre találtam néhány valódi FM-rádió kezelő alkalmazást is. Többet is kipróbáltam, de mindegyik egy dolgon vérzett el, ami számomra alap-feltétel volt: nem tudják kihangosítani az adást a telefon hangszórójára. Amikor elkezdtem kutatni az okot, kiderült, hogy nem a fejlesztőkkel van a baj, hanem állítólag a MS nem valósította meg (implementálta) azt a csatolófelületet (API), amin keresztül ez megoldható lett volna. Szóval ez egy újabb fekete pont MS-nek 😦 (S mielőtt valakiben felmerül, attól még nem váltok készüléket 😉 ).

Windows frissítés

december 12, 2016 4 hozzászólás

Nem azt mondom, hogy ez az első olyan kumulatív Windows-frissítés, ami problémás, de mindenképp figyelemre méltó, hogy mekkora galibát tud okozni. A mostani, valamiért rendkívüli, dec. 9-i KB3201845 frissítésről van szó, ami a javítási listában semmi hálózattal kapcsolatos dolgot nem említ, de vannak, akik panaszkodnak, hogy a számítógépük a telepítés után nem csatlakozik a hálózathoz. Az ok egyszerű: valamiért a gépek APIPA-címet kapnak, nem a rendes, DHCP-kiszolgálótól kapott címet. A megoldás kétféle is lehet: egyrészt átállítani fix IP-címre (no igen, egy nagymamának ezt telefonon elmondani, hogy miként lehet), illetve egy újraindítás a frissítés telepítése után.

S itt ismét előjön az a kérdés, amivel már gyakorlatban is sokszor találkozom: nem ugyanaz a leállítás, majd indítás, mint az újraindítás. Ennek okáról mintha már írtam volna: az újabb oprendszerek leállítás során nem végeznek „teljes” munkát, pont azért, hogy indításnál gyorsabban induljon a számítógép. Ez végső soron a felhasználók kényelmi funkciója, de néha nem árt egy „valódi” újraindítás. Aki meg nem szeretne újraindítani, annak egy pipa-lehetősége van, kikapcsolni ezt a szolgáltatást.

Ha meg belegondolunk, az ilyenek fényében nem biztos, hogy jó dolog volt átállítani a régi (Win7…) gépek frissítését is összesítő frissítésekre. Értem én a dolog technikai oldalát, de akkor is 😦

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

Hyper-V guest vs. USB

november 10, 2016 6 hozzászólás

Adott helyen ismét előkerült egy ősrégi probléma: Hyper-V vendéggépre szerették volna a gazdagép USB-portjára csatlakoztatott eszközt átvinni. Ez sajnos mindig egy fájó pont, kerülő-megoldásokkal próbáltuk itt is megoldani a problémát.

Egyrészt megoldás lehet a távoli asztali kapcsolat (RDP), hiszen annak beállításai között szerepel a helyi USB-erőforrások átadása. De mi van abban az esetben, ha (bármilyen okból kifolyólag) nem szeretnénk hálózattal ellátni a vendég-gépet? Ekkor az RDP bizony nem járható út.

Egy másik megközelítés a 2012 R2 óta létező korlátozott megoldás. Ehhez ugyanis Gen2 gépek szükségesek, s ebben az esetben a VMBus-on keresztül át tudjuk adni a legtöbb USB-eszköz kezelését a vendég-gépnek (természetesen bekapcsolt Enhanced Session Mode kapcsolóval). Sajnos a Gen2 gépeknek elég komoly korlátozásai vannak, a konkrét esetben 32-bites Win7 futtatására lett volna szükség – ez sajnos “duplán” megbukott (32-bit és Win7).

Mivel szerencsére itt a saját gépen megvalósítandó környezet elég (értsd: nem távoli szerveren, automatikusan induló virtuális gép, stb), így kipróbáltunk egy alternatív virtualizációs eszközt, a VirtualBox-ot is. Ez bizonyos dolgokat nem tud, amire egy “rendes” virtualizációs réteg képes, de erre a feladatra akár alkalmas lehet.

Hogy ott, adott környezetben annyira speciális USB-eszköz volt, hogy sem az RDP-s megközelítés, sem a VirtualBox nem hozott megoldást – hát, sajnos van ilyen…

Kategóriák:Virtual Server/Hyper-V Címke: ,

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.

Exchange mentések vs Hyper-V

szeptember 15, 2016 Hozzászólás

Adott helyen egy VM (történetesen egy Exchange) átkerült egy 2012-es gazdagépről egy 2012 R2-t futtató gépre. A mozgatás után látszólag minden rendben működött, így a rendszergazda kollégák nem bolygatták többet.

Egy bizonyos idő eltelte után a szerver nem volt hajlandó fogadni a leveleket, a monitorozó-rendszer erőforráshiányra panaszkodott. Megnézve a paramétereket, a kollégák egyből kiszúrták, hogy itt bizony merevlemez-kapacitás hiányzik, s tudjuk, hogy az Exchange-be épített Back-pressure hatására inkább visszautasítja a levelek fogadását, mint veszélyeztesse „saját épségét”. Tüneti kezelésként gyorsan felszabadítottak némi helyet, de természetesen nem hagyták annyiban a dolgot, biztos, ami biztos alapon segítséget is kértek.

Utánajárva, hogy miért lett tele a kötet, kiderült, hogy a naplók törlése nem történt meg (ez akkor történik meg, amikor egy teljes mentés készül az Exchange-ről). Kiderült, hogy magán a levelező szerveren nem volt beállítva mentés, de a gazdagépen viszont igen, mégpedig a teljes VM mentése. Ez „triggerelni” szokta az Exchange-logok törlését is, itt viszont nem történt meg. Az okot keresve elég hamar rátaláltunk, hogy mikor volt az utolsó teljes mentés (Exchange-konzol segítségével kiolvasható), majd mivel a jelzett dátum körül történt a mozgatás, nyilvánvalóvá vált, hogy ezzel függ össze. Szerencsére a gazdagép Hyper-V konzolját megnyitva egyből látszott a probléma: az Integration Services (itt írtam róla legutóbb) nem volt naprakész. A friss, 2012 R2-s kiegészítőket telepítve, majd a VM-et újraindítva a következő mentés egyből ismét helyreállította a rendet.