Archívum

Archive for the ‘Windows 7’ Category

Hangfelolvasás (Text-To-Speech)

január 7, 2019 3 hozzászólás

Aki ismer, tudja, hogy vannak olyan általam kezelt rendszerek is, amelyeket megváltozott munkaképességű embereket foglalkoztató cégek használnak.

Ennek (és az Office 2019) kapcsán merült fel, hogy még nem írtam az egyik lehetőségről, amely ilyen embereken segíthet: a szöveg-felolvasásról (angol rövidítéssel TTS).

Anélkül, hogy kitérnék különböző third-party gyártókra, kezdjük az alapokkal. Windows Vista és Win7-re telepíthető a Microsoft Speech Platform (pillanatnyilag 11.0), erre épülnek a hivatkozott oldalon található “Related resources“-ban felsorolt nyelvek – de maradva az aktuálisabb verzióknál, Win8-8.1-10 esetén a platform már alapból adott.

A platformot használó alkalmazások közül most az Office-t emelném ki, ezen keresztül magyaráznám el a cikk egyik apropóját. Az említett programcsomagban (a 2010-es verziótól) beépítve megtalálható a Speek funkció, amely segítségével – a kiadás verziójától függően – a OneNote, Outlook, PowerPoint és Word (bizonyos esetben Excel) komponensekkel használható a felolvasás.

A felolvastatás jobb megértéséhez mindenképp tisztázzuk azt, hogy (általában*) milyen nyelven kerül felolvasásra a szöveg: a szöveg nyelve alatt (ez adta az egész cikk alapját) az adott szó (mint legkisebb egység) ellenőrzés nyelvét (helyesírás és nyelvhelyesség ellenőrzés) értjük. Méginkább pontosítva: a szó első betűjének a nyelvi beállítása a mérvadó.

Így érkeztünk el a fekete leveshez. Előfordul, hogy az Office-ban hiába vesszük fel a Felolvasás menüpontot az eszköztárra, az szürke marad (vagy Outlookban hiába klikkelünk rá, nem történik semmi). Ez az előbb leírtakból adódik: a szöveg nyelvének egyeznie kell a telepített nyelvek egyikével (s itt a Vezérlőpultban található nyelvekre koncentráljunk). Tekintettel arra, hogy a listában nincs magyar nyelv, eddig ez a funkció eléggé hanyagolásra került.

De jöjjön az egyik jó hír 😊 Az újabb operációs rendszerek (Win8+) kétféle felolvasó-motorral rendelkeznek. Egyrészt vannak a WinRT speech synthesis API-k (a Windows.Media.SpeechSynthesis névtérben) az új motor használatára, illetve a SAPI speech synthesis API-k (a System.Speech.Synthesis névtérben és a COM ISpVoice csatlakozóval) a régi felolvasó működtetésére.

Ezek után kétfelé válik a történet. Lesznek a “hagyományos”, desktop alkalmazások (mint pl. az Office), illetve az új, “modern” fejlesztések (pl. az Edge, Narrator). A nyelv kiválasztásánál képbe jön a Vezérlőpult vs Beállítások (Control Panel vs Settings) kombó által okozott felfordulás is. A Settings/Time and Language/Speech részen az új motor alapértelmezett hangját, míg a Control Panel/Speech recognition/Text to speech beállításával a régi, “SAPI” alapértelmezett hangját választhatjuk ki. A két beállítás nem lesz koherens, ezt próbálják valamilyen szinten jelezni a Vezérlőpultban található nyelveknél a “Desktop” utótaggal is. Ennek ugyanakkor oka van: pl. az új TTS esetén ki tudjuk választani Microsoft Szabolcs-ot, mint magyar hang (a Preview voice segítségével meg is tudjuk hallgatni), viszont a Vezérlőpultban még mindig az angol David lesz beállítva – sőt, ott nem is tudjuk kiválasztani Szabolcsot. Tekintettel arra, hogy a SAPI családot már nem fejlesztik/bővítik, javasolt áttérni a WinRT-s motorra (bár ha egy nyelvi csomagban, ami alapértelmezetten új hangokat telepít, van SAPI hang is, az még telepítésre kerülhet).

Ez a kettősség fog mostantól végigkísérni, ugyanis alkalmazástól függően (ami általában egyik szintetizátor használatára van megírva) tudjuk majd kiválasztani a hangot (amennyiben van beépítve ilyen lehetőség, ellenkező esetben az előbb leírt helyen kijelölt hang marad). Amennyiben mindkét API-csomagot tudja kezelni (pl. a Narrator), úgy a “Desktop” utótag segít eldönteni, hogy az adott nyelv melyik motorra íródott. S akkor most kicsit visszakanyarodnánk az Office-hoz (de bármelyik programról lehetne szó): amennyiben nincs lehetőségünk magyar nyelvre (mert az még SAPI motort használ), akkor ne a beépített (Office esetén Speek) funkciót használjuk, hanem más felolvasót (igen, pl. a már sokat említett Narrator-t, ami egy “általános” felolvasó).

S akkor ejtsünk pár szót a hangok telepítéséről. A megszólaló nyelvek telepítése a fogaskerék (Beállítások) segítségével történik: Settings/Time and Language/Language alatt felsorolt listában lehet látni a jelenlegi állapotot, ahol a nyelv melletti ikonok jelzik, hogy az adott nyelv mely komponensei kerültek telepítésre (én jelen cikkben most csak a kimenettel, azaz a felolvasással foglalkozom):


Amennyiben nincs telepítve az adott komponens, akkor az adott nyelv Options menüpontjából telepíthetjük a Speech funkciót (nyelvtől függően – mint a magyar esetén is – előfordul, hogy csak a TTS-t telepíti, a hangalapú bevitelt nem).

Következzen a második jó hír, amihez ismét visszakanyarodunk az Office-hoz, konkrétabban az Office 2019-hez. Itt ugyanis, amikor kitennénk a Felolvasás parancsikont az eszköztárra, akkor érdemes figyelni, hogy két ilyen parancsunk is van.


Amelyik “buborék” formájú, az SAPI, az “A” betűs másik pedig WinRT alapú felolvasást tesz lehetővé – magyarul végre ez a termék is elkezdte használni az új motort. 😊 A gyorselérési eszköztárban pl. így néz ki a két ikon:


Mint említettem, Office (2019 előtt) esetén ha SAPI felolvasást végeztetünk, akkor tudjuk csak “megnyomni” a gombot, ha a szöveg nyelvével azonos nyelvű SAPI telepítve van (ha nincs, szürke a választási lehetőség). Ha a WinRT felolvasást választjuk, akkor kétfelé válik a történet: ha nincs telepítve az adott nyelvi TTS-modul, akkor a beállított nyelven megpróbálja felolvasni úgy, ahogy tudja (erre utal a korábbi * hivatkozás). Ha viszont telepítve van az adott nyelv TTS-e közül bármelyik, akkor azon a hangon szólaltatja meg. Sőt, ne feledjük: az adott szó nyelve számít, tehát egy mondatban is tudjuk keverni a nyelveket, s így mikor David (vagy Zira, az angol női hangról még nem is beszéltünk), mikor Szabolcs fog hozzánk szólni – kész kabaré 😊

Az új motor használatáról érdemes tudnunk, hogy egy általános alkalmazás (pl. Edge esetén) a lejátszást vezérlők melletti “beszélő emberke” ikon, Office esetén a “fogaskerekes hangszóró” ikon segítségével tudjuk kiválasztani a hangot:


Az egyik fontos különbség, hogy pl. Edge-nél (ahol nincs megadva a szöveg nyelve) kiválasztható minden (WinRT-s) hang, Office esetén viszont csak a kijelölt szöveg (vagy aktuális kurzorpozíció) nyelvének megfelelő hangok közül lehet kiválasztani (pl. a Settings-ben alapértelmezetten beállított David helyett Zira vagy Mark).

u.i. friss hír, hogy a 19H1 verzióban a Narrator tovább fejlődik…

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

BitLocker kulcsok házirendben szabályozva

április 19, 2017 Hozzászólás

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:

  1. 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
  2. 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é.

Milyen Windows telepítő van a kezemben?

február 2, 2015 3 hozzászólás

Egyik cégnél a leltározás/rendrakás során az IT osztályon előkerült több olyan adathordozó, amelyikről nem tudták pontosan megmondani, hogy mi is található rajta. Amit tudtak, hogy valamilyen telepítő-készlet, de se a verzióját, se a nyelvét nem tudták megmondani (s most ne kössünk beléjük, hogy milyen hanyagok voltak 🙂 ).

Szerencsére van egy aránylag egyszerű mód, amivel ezeket az adatokat ki lehet olvasni. Ehhez menjünk a telepítő Sources könyvtárába, s ott a következőket ellenőrizzük:

IDWBINFO.txt: ez megmutatja, hogy milyen architektúra (AMD64, x86), milyen típus (FRE), melyik alverzió (pl. winblue_Rtm, win8_rtm, win7sp1_rtm, win7_rtm).

Lang.ini: mint a neve is mutatja, a telepítő nyelvéről ad információt

Hogy szerver vagy kliens-ről van szó, ugyanez a könyvtár segít: ha létezik \sources\background_svr.bmp , akkor kiszolgáló, ha viszont \sources\background_cli.bmp van helyette, akkor kliens OS-ről beszélünk.

Ei.cfg: bár leginkább telepítésekhez használjuk, amennyiben létezik ez az állomány, segíthet, hogy milyen SKU, milyen csatorna és hogy VL-telepítőről van-e szó (figyelem, ez nem biztos, hogy a telepítőn található minden SKU-t felsorol!). A cikkel ellentétben a Channel lehet Volume is.

Amennyiben nincs az előző állomány, vagy pontos infókat akarunk, akkor egyszerűen csak emelt szinten futassuk le az alábbi parancsot:

dism /get-wiminfo /wimfile:”f:\sources\install.wim”

A fentiek során kaphatunk egy pontos képet, hogy melyik OS, melyik SKU, milyen architektúra, milyen nyelvű és milyen csatornán értékesített telepítővel rendelkezünk 🙂

Explorer – Discovery method

november 3, 2014 Hozzászólás

Előző kérdés megoldása során felmerült az Intézőben a különböző oszlopok láthatóságának bekapcsolása. A kolléga az alap-kinézet bővítése után találkozott először azzal, hogy a Discovery Method oszlop több értékkel is rendelkezhet, illetve WSD érték alapján látjuk (többek között) az ip-címet is – így szeretett volna egy kicsit többet tudni ezekről, én meg úgy gondoltam, másoknak is hasznos lehet.

Na de akkor nézzük az oszlopokat: a Name és Workgroup oszlop egyértelmű, hiszen a távoli számítógép adatai. A Category is aránylag egyértelmű, bár az egyes-szám/többes-szám logikát nem értem (Computer vs Printers vagy Multifunction Devices).

1. Network location

A „Network location / Hálózati hely” esetén már kezdődnek a bonyodalmak, hiszen itt az a helyi hálózati kapcsolat megnevezése fog szerepelni, amelyiken történt a felderítés.

A hálózatok típusának szétválasztása Windows Vista-tól lett bevezetve, s a Windows klienseken grafikus felületen meg tudtuk változtatni a hálózat nevét, ikonját és típusát (Home/Work = Private, Public – a tartományi természetesen nem választható, de a rendszer felismeri). A Network List service szolgáltatás a Network Location Awareness segítségével azonosítja a hálózatot, ahol az NLA az alapértelmezett átjárót vagy az SSID-t használja egy hálózat azonosítására (bizonyos esetekben Unknown lehet).

Windows 8 esetén már nincs ikonja a hálózatnak, valamint a másik két elem grafikus módosítása is megszűnt – helyette maradt az eddig is létező két alternatíva: a „tartós” módosítás (ez volt kivezetve grafikusan) és egy light-os verzió.

A „hard” módosítás a registry-szerkesztés, ekkor a

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles

kulcs alatt a ProfileName értékét (név esetén), típushoz a Category értékét (0=Public, 1=Private, 2=tartományi) tudjuk módosítani. Ha viszont nem szeretnénk a registry-ben turkálni, egy light-os verzióra is van lehetőségünk, ha nem otthoni verzió az oprendszerünk: a Secpol.msc konzol segítségével a „Network List Manager Policies”-ben tudjuk módosítani a hálózati hely említett paramétereit.

Ha inkább viszont PowerShell a kedvencünk, akkor pl. Get-NetConnectionProfile –al lekérjük, majd

Set-NetConnectionProfile -InterfaceIndex [azonosító] -NetworkCategory Private

segítségével változtathatjuk pl. a típust (ez „tartós” módosítást végez).

2. Discovery Method

A másik problémás oszlop a „Discovery method / Keresési módszer”. XP-s korszakban egyértelmű volt a gépek tallózása, amely a NetBios-ra és a Computer browser szolgáltatásra alapult. Ez az aktuális oprendszereknél is megvan, bár kis csavarral: alapból a Computer browser szolgáltatás nem fut, de a NetBios engedélyezve van.

Ekkor jön képbe a „másik” felderítő eszköz-csoport (Function Discovery), amelyik többek között a WS-D (Web Services Dynamic Discovery) protokollt használja – ennek ugye kifejezetten az a célja, hogy erőforrás-szolgáltatásokat keressen a helyi hálózaton. Ez két szolgáltatást is takar, ebből az egyik a felderítést végző szolgáltatás (FDPH – Function Discovery Provider Host), a másik pedig a gép saját erőforrásait publikáló szolgáltatás (FDRP – Function Discovery Resource Publication).

Amennyiben engedélyezzük a hálózati erőforrások felderítését („sárga csík”, illetve Control Panel\All Control Panel Items\Network and Sharing Center\Advanced sharing settings), érdemes figyelnünk a hozzá kapcsolható szolgáltatásokra is: DNS Client, Function Discovery Resource Publication, SSDP Discovery, UPnP Device Host.

Első körben ellenőrizzük a felderítő-szolgáltatást, ugyanis ha nem fut a FDPH, akkor nem tudjuk feltérképezni a WSD eszközöket. Természetesen a teljes összhanghoz szükség van a másik oldalon a publikálásra, ott az érdemes tudni, hogy amint fut az erőforrás-megosztás szolgáltatása (akár úgy, hogy mindkét módon elérhető), a WSD elsőbbséget élvez a hagyományos módszerrel szemben, így azonnal leváltja a Netbios-os elérést.

Igaz, hogy itt most jellemzően WSD-ről írok, de jobban a motorház alá nézve láthatjuk, hogy az FDP (Function Discovery providers) több módszert is használ a felderíthető erőforrások listázására, a beépített szolgáltatók listája: NetBIOS, PnP, Registry, SSDP, WCN és WSD. Ha módosítani szeretnénk a felderítési módszereket (óvatosan, hiszen ez akár más hálózati gondhoz is vezethet), ezek közül néhányat ki lehet kapcsolni (pl. a hozzá tartozó szolgáltatlás leállításával), de értelemszerűen pl. a registry-t nem lehet leállítani – de ez már egy másik szint…

Számítógép leírása

október 1, 2014 1 hozzászólás

Elég sokan találkozhattak azzal, hogy a gép nevén kívül meg lehet adni a gépnek egy leírást is. S itt most nem az AD-ban található leírásról van szó – bár, hogy miért nem lehet összekötni a gép leírásával, automatikusan, tartományba léptetés esetén, nem igazán értem. Mivel itt nincsenek kikötések (mint a gép nevében), ez a későbbiekben segít nekünk azonosítani a gépet a hálózaton, akár otthon is (pl. „Marci gépe”), munkahely esetén pedig egy nagyobb hálózatban kimondottan jól jöhet.

Kezdjük a régi módszerrel. XP esetén a Számítógép/Kezelés, gyökéren állva jobb klikk/Tulajdonságok, s ott a második fülön lehet könnyen, grafikus felületen beírni. Sőt, ez működött abban az esetben is, ha mondjuk egy másik XP-ről Mmc használatával csatlakoztunk, így ezt a mezőt távolról is tudtuk kezelni.

Vista után megváltozott a helyzet, ugyanis a grafikus kivezetése máshova került. Mostantól helyi gépen a System (Rendszer) oldalon lehet beállítani, ami a My Computer/Computer/This PC (2003/2008/2012 átnevezőkommandó) Tulajdonságai-nak felel meg. A gond ezzel csak az, hogy ezt a felületet távolról nem tudjuk elérni, így maradnak az alternatív megoldások, pl. registry-írás. Ehhez azt kell tudnunk, hogy ezt az adatot a gép a

HKLM\SYSTEM\CurrentControlSet\services\LanmanServer\Parameters

kulcsban tárolja, srvcomment névvel illetett Reg_SZ értékben.

Ha megvan az adat módosítása, akkor következzen a lekérdezés. XP esetén nincs nehéz dolgunk, mert a hálózat megjelenítésénél a Név mellett található a Megjegyzések oszlop is, ami tartalmazza a keresett leírást. Sőt, a Név maga is tartalmazza, s emlékszem arra is, hogy mekkora öröm volt, amikor végre egy registry-kulcs szerkesztésével az alapértelmezett „Megjegyzés (Számítógépnév)” formát át lehetett alakítani „Számítógépnév (Megjegyzés)” alakúra – így nem bomlott meg a felsorolási logika akkor sem, ha nem minden géphez volt rendelve megjegyzés.

Új generációs oprendszerek esetén viszont már gondban leszünk. Használható ugyan továbbra is az elődöknél megszokott „Net View” parancssoros eszköz, de grafikusan nem tudjuk könnyen elővarázsolni a kért adatokat. A szokásos Intézőben hiába nyitjuk meg a hálózati eszközöket felsoroló listát, ott nem tudunk olyan oszlopot kiválasztani*, ami tartalmazná a Megjegyzések értékeit. Helyette vagy egy XP-n létrehozott parancsikont kell átmásoljunk a célgépre, vagy ott hozzuk létre azt a könyvtárat, aminek a „Network.{208d2c60-3aea-1069-a2d7-08002b30309d}” nevet adjuk.

Végezetül még egy apróság. Ha nem akarunk sokat keresgélni, hogy miként tudjuk az AD-t lekérdezni (most ugye gépekre gondolok), akkor mentsük le az alábbi sorokat egy .qds kiterjesztésű állományba:

[CommonQuery]

Handler=5EE6238AC231D011891C00A024AB2DBBC1

Form=00670016AD87D011914000AA00C16E65A1

[DsQuery]

ViewMode=0413000017

EnableFilter=0000000000

[Microsoft.Computers]

MachineRole=0000000000

[Microsoft.PropertyWell]

Items=0000000000

A fenti állományt futtatva, kilistázza az AD-ban található gépeket – alapértelmezetten az ott található leírásokkal együtt (ami, ugye tudjuk, nem ugyanaz, mint a számítógép helyi leírása…)

* a kérdést felvető kolléga kérésére erre vonatkozóan még lesz egy cikk

NumLock a Windows indulasakor – újra

február 17, 2014 Hozzászólás

Eredetileg ennek a cikknek a hozzászólóinak szintén kommentként akartam válaszolni, de úgy döntöttem, inkább egy új bejegyzést írok.

Az általam leírtak megtalálhatóak a KB154529-ban is, de a neten elég sok cikk foglalkozik ennek beállításával (pl. bejelentkezés után házirend segítségével).

Ami változott: Windows 7 óta már nem 0 található a Reg_SZ értékben, hanem egy hexabites szám, a 0x80000000-nak a tízes számrendszerbeli megfelelője, a 2147483648 lesz az alapértelmezett. Ennek alapján az eddigi 2 helyett a 2147483650 is elfogadható érték (mindkettőt elfogadja!)

Tapasztalatom alapján viszont a működéshez sokszor még az is szükséges, hogy a Gyors rendszerindítás-t kikapcsoljuk (aki magyar oprendszert használ, annak Win+x, Főkapcsoló lehetőségei, jobboldalt a „A főkapcsolók funkciójának megadása”, majd baloldalt a „Leállítási beállítások”-nál az első pipa).

Aki parancs-sorban gondolkozik, annak a

HKLM\System\CurrentControlSet\Control\Session Manager\Power

kulcson belül HiberbootEnabled duplaszó értéket az 1 helyett 0-ra kell állítani.

Kategóriák:General, Windows 7, Windows 8 Címkék:

JVM Launcher

február 22, 2013 2 hozzászólás

Az egész úgy kezdődött, hogy a Nokia visszaütött 🙂 Komolyra fordítva a szót, egy adott gépen szerette volna az ügyfél az egyik bevallást telepíteni az ÁNYK-ba (leánykori nevén AbevJava), s a „Could not find the main class: bevallás.jar. Program will exit.” hibaüzenetet kapta:

JVM_error

Elég hamar sikerült eljutni addig a pontig, hogy a ludas a telepített Nokia Ovi Suite alkalmazás, amellyel egyszer már meggyűlt a bajom. Jelen esetben „elvette” a .jar állományok futtatását, mindenképp ő szerette volna azokat kezelni a JVM helyett.

Semmi gond, átállítom az alapértelmezés szerinti programot, s máris megoldódik a probléma – gondoltam szerényen. Nos, ez addig tartott, amíg ki nem próbáltam. Ugyanis hiába klikkeltem, állítottam grafikus felületen, hogy márpedig ne ez legyen az elsődleges, magasról tett rá a rendszer. Ja, elfelejtettem megemlíteni, hogy Win7 rendszerről lévén szó, a Start menü/Default programs/Associate a file type or protocol with specific program beállításainál ki tudjuk ugyan választani a programot, de esetünkben ez azért nem elég, mert paraméterként át kell tudjuk adni a futtatandó állomány nevét. XP esetében nincs gond, ott tudjuk szerkeszteni az átadás módját, a megnyitás mibenlétét – W7 esetén grafikusan nincs ilyen lehetőségünk.

A következő lépés a kézi beállítás volt. Az Ftype utasítást már ismerjük, ezért az alábbi utasításokat futtattam le:

assoc .jar=jarfile

ftype jarfile=”C:\Program Files\Java\jre7\bin\javaw.exe” -jar “%1” %*

Ez már annyiban jobb lett, hogy ekkor már átadásra került paraméterként az állomány neve, de továbbra sem volt hajlandó elindulni.

Rákeresve a neten, kiderült, hogy nem egyelülálló problémával állok szemben, mások is belefutottak ebbe, annyi különbséggel, hogy náluk a „.jar”-t tartalmazó registry-kulcsok törlése, majd a fentihez hasonló beállítás megoldotta a problémát. Esetünkben viszont továbbra sem segített.

Mivel elég sok időm már ráment, másik megközelítést választottam. Tudtam, hogy létezik egy másik olyan gép, amelyiken ez teljesen jól működik, s habár az XP OS-el rendelkezik, kimentettem a registry-jéből mindazokat a kulcsokat, amelyek szerepet játszhatnak a .jar kiterjesztés kezelésében.

Ennek importálása után a probléma nem oldódott meg azonnal, de utána grafikus felületen ismét kiválasztva, hogy a JVM legyen az alapértelmezett program, hátradőlhettem, hogy ismét sikerült átvernem a Nokia programját 🙂

Kategóriák:General, Windows 7 Címkék:

Windows 8/2012 vs. Hyper-V 2.0

december 25, 2012 Hozzászólás

A blogomon már felmerült egy olyan zavaró hiányosság, ami nagyobb negatívumot jelent számomra, mint a Start menü átalakulása. Most egy másik ilyen dologról szeretnék írni: az újabb rendszerekről (Win8/2012) nem lehet régebbi Hyper-V rendszereket kezelni.

Megpróbálhatjuk telepíteni a Windows 7-es RSAT-ot, de ez egyrészt nem javasolt (nem hiába adnak ki minden OS-hez külön RSAT-ot), másrészt hibára is fog futni (Error 0x80096002). Ha pedig feltesszük a saját eszköztárat, akkor azzal nem fogunk tudni csatlakozni régebbi Hyper-V rendszerekhez (The operation on computer „Computer” failed).

Az ok itt van leírva. Van néhány kerülő-megoldás (távoli asztal használata, egy „régebbi” op-rendszert futtató virtuális gép, illetve a nagyágyú, az SCVMM 2012 SP1), de ha belegondolunk, akkor első esetben pont az a kényelem szűnik meg, ami jelen rendszerekben került végre bevezetésre (egy gépről vezéreljük a kiszolgálóinkat); második esetben újabb licenc szükséges; míg harmadik esetben nem kis kiadásba keveredhetünk…

Az előző gondolathoz annyi pontosítás illik, hogy mondjuk egy Windows 7/2008 R2-es rendszerről vezérelhetjük a Hyper-V 3.0 rendszereket (a cikkben is leírt, kompatibilitás megvalósított volta miatt), de jelen bejegyzésem ennek fordítottját próbálja taglalni.

Bár Windows 8-ra nem használható, de ha mondjuk egy Windows 2012 kiszolgálóról szeretnénk elérni Hyper-V 2.0 kiszolgálóinkat, létezik egy 3rd party, ingyenes alkalmazás: 5nine Manager for Hyper-V 3.0. Ezt telepítjük a kiszolgálóra, s amennyiben a kezelendő platform teljesíti a feltételeket, szinte ugyanazokat a műveleteket tudjuk végrehajtani, mint a beépített Hyper-V Manager-el. Van néhány dolog, amit csak a Full, fizetős verzióval tudunk végrehajtani (pl. csatlakozni a virtuális géphez), de az alapfeladatok ellátására teljesen alkalmas.

Nyomtató-meghajtó eltávolítási gondok

november 13, 2012 2 hozzászólás

Adott helyen, egy Windows 7 kliensen egy nem megfelelő nyomtató-meghajtó került telepítésre. Ez most konkrétan azt takarta, hogy egy Windows 2003/XP-re készült meghajtó lett feltéve, de a nyomtató entitásának létrehozásánál folyamatosan hibaüzenetet dobott. Sőt, a nyomtató-kezelő annyira bedurvult, hogy a semmilyen módon nem lehetett eltávolítani, mert arra hivatkozott, hogy használatban van:

Unable to remove <printer driver name and type>. The specified printer driver is currently in use.


Ilyenkor több ötlet merülhet fel, érdemes az alábbi sorrendben megpróbálni:

  • újraindítani a Nyomtató-kiszolgáló szolgáltatást (Spooler) és utána egyből megpróbálni törölni a kérdéses meghajtót
  • a registry-ben átnevezni a nyomtató-feldolgozót – hogy életbe lépjen, újra kell indítani a szolgáltatást – s gyorsan törölni a meghajtót, majd utána természetesen visszanevezni a kérdéses kulcsot:

    HKLM\System\CurrentControlSet\Control\Print\Environments\Windows x64\Print Processors

  • ha az előbbi sem segít, érdemes megpróbálni a Client Side Rendering Printer Provider kulcsot exportálni (ha netalán valami gubanc lesz), majd törölni (természetesen ezután is szolgáltatás-újraindítás szükséges) – ezután már valószínűleg csont nélkül tudjuk majd eltávolítani a meghajtót:

    HKLM\Software\Microsoft\Windows NT\CurrentVersion\Print\Providers\Client Side Rendering Print Provider

Hogy kicsit jobban megértsük a fenti kulcsot, a következőket kell tudnunk – ezzel folytatva eddigi ismereteinket.

A Client-Side Rendering (CSR) egy Windows Vista/Server 2008 operációs rendszerekkel bevezetett s alapértelmezetten engedélyezett funkció, amely lehetővé teszi a nyomtatási feladatok teljes mértékű ügyfél-oldali feldolgozását – amennyiben a megosztott nyomtató egy ilyen (vagy újabb) operációs rendszerrel rendelkező nyomtatókiszolgálón található. Miután az ügyfél feldolgozta a kérést, a nyomtatási feladatot átküldi a nyomtatószervernek a várakozási sorba sorolására és nyomtatásra anélkül, hogy további kiszolgáló-oldali renderelés lenne szükséges.

Ennek menete: a CSR engedélyezett állapotában a nyomtatási feladat az ügyfélgépen egy gyors EMF (Enhanced MetaFile) feldolgozásra kerül, ezáltal az alkalmazás nagyon hamar vissza tudja kapni a vezérlést. Az ügyfél nyomtató-illesztőprogramja ezután átalakítja (rendereli) a sorbaállított EMF adatokat a kért nyomtatóhoz megadott Page Description Language (PDL)-re, mint például a PCL vagy PostScript, majd a kapott RAW-formátumú adatfolyamot átküldi a nyomtatókiszolgáló várólistájába. A RAW adattípus eszköz-specifikus, és jelzi a távoli nyomtatásisor-kezelőnek, hogy a nyomtatási feladatot már feldolgozták a nyomtató illesztőprogramjával, így kiküldhető közvetlenül a nyomtatóra, vagy letárolhatja spool állományként.

Amellett, hogy átmozgattuk a nyomtatási feladat feldolgozásával járó terhelést a szerverről a kliensre, ezzel javítva a nyomtatókiszolgáló teljesítményét és skálázhatóságát, a CSR további előnyökkel bír, mint például:

  • illesztőprogramok eltéréseinek megszüntetése: mivel a számítógép az EMF-formátumú adatokat már renderelte, nincsenek olyan ellentmondások, amelyek régebben az ügyfél / kiszolgáló nyomtató-illesztőprogram eltéréseiből adódtak.
  • offline nyomtatás támogatása: akkor is lehet megosztott nyomtatóra feladatot küldeni, ha nincs kapcsolat a nyomtatókiszolgálóval. Amint a kliens számítógép ismét kapcsolatot létesít a kiszolgálóval, a renderelt nyomtatási feladat automatikusan kiküldésre kerül.
Kategóriák:General, Windows 7 Címkék: ,