Archívum

Archive for the ‘Windows 8’ 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…

MAPI “unspecified error”

június 27, 2018 1 hozzászólás

Adott helyen egy Outlook-os problémában a segítségem. Előzményként annyit érdemes tudni, hogy elkezdték bevezetni a Windows 10-et, a jelenlegi Windows 8.1 leváltására, míg Office tekintetében egyelőre még 2013 került a gépekre (jelen esetben fontos, hogy nem in-place upgrade történt).

Azokon a gépeken, ahol Win10 futott, bár ugyanúgy alapértelmezett levelező-klienssé volt téve az Outlook, ettől függetlenül egy bármilyen Office termék (Word, Excel, …) esetén, amennyiben Fájl/Megosztás/E-mail bármelyik almenüpontjára klikkeltek, egy hibaüzenetet kaptak, s nem tudták elküldeni a levelet:

Az eseménynaplót megnézve, szintén nem volt bővebb információ:

Időnként, hogy ne legyen egyszerű a történet, néha még az alábbi hibaüzenet is felpattant:

Ez utóbbi alapján próbáltak elindulni. Nos, a kapott képernyőmentések viszont azt állították, hogy mégiscsak jól van minden beállítva:

Sajnos az eredeti hibaüzenet (a MAPI-s) elég semmitmondó, a második (alapértelmezett kliens) pedig érthetetlennek tűnt. Körbejárva a problémát, kiderült, hogy bár látszólag valóban mindenhol az Outlook az alapértelmezett (pontosabban fájltípus és protokoll tekintetében az is, pl. egy mailto: rendben működött), a háttérben a grafikus felület egy registry-bejegyzést nem állít át. Ez Win8.1-en nem okoz gondot, mert az nem veszi figyelembe, Win10 esetén viszont fontos, hogy a

HKLM\Software\Clients\Mail kulcsnak a Default értéke Microsoft Outlook legyen (még üres sem felel meg neki).

Szerencsére mindezt házirend segítségével is ki lehet szórni, tehát egy több gépes környezetben is megoldódik a probléma – bár ezt csak egyszer kell átállítani, tehát ha minden gépen lefutott, a házirend törölhető is 😊

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

RDS Manager on Windows 2012 R2

február 13, 2015 Hozzászólás

Aki 2003/2008-as környezetből érkezett a 2012-be, s a régi rendszeren használt TS/RDS-t, az szinte biztos mérgelődőtt már az RDS Manager (tsadmin) hiányán. Mint tudjuk, ez volt az az eszköz, amelyikkel ki tudtuk listázni, hogy ki milyen azonosítóval csatlakozott, tudtunk neki üzenetet küldeni, sőt, még szükség esetén távsegítséget is nyújthattunk úgy, hogy egyszerre láttuk ugyanazt a képernyőn.

Ez a képesség sajnos teljesen eltávolításra került a 2012*-ből, ezért vagy szívtuk a fogunkat, vagy alternatív megoldásokat használtunk (pl. Remote Assistance vagy ez). Szerencsére a sok panasz hatására az újabb, R2 verzióban valamilyen formában visszaköszön, még ha nem is a régi, jól megszokott eszközök segítségével, de van egy lehetőségünk natívan kezelni a távoli munkameneteket.

Kezdjük a rossz hírekkel. Ahhoz, hogy grafikus felületről használni tudjuk, fel kell telepítenünk egy RDS környezetet, különben nem kapjuk meg a grafikus kezelőeszközt. Ebből egyértelműen következik a másik rossz, hogy ha csak admin módban használjuk a távoli asztalokat, akkor grafikus felületről nem tudunk csatlakozni a rendszergazda kolléga munkamenetéhez sem… Mielőtt még valaki azt gondolná, hogy utóbbihoz kicsit trükközik, s egy adott gépre telepíti az RDS környezetet, majd ezt a gépet felveszi egy másik gép Server Manager-ébe, ezzel megkapva az RDSM-et – nos, sajnos attól még továbbra is csak az RDS farm munkameneteit fogja látni/kezelni – ismétlem, grafikusan.

Nézzük akkor, hogy mit lehet. Az RDSM eszköz Connections oszlopában látjuk az aktív munkameneteket, s az ezek közül kiválasztotton jobb egérgomb segítségével kérhetjük a Shadow opciót, ezzel csatlakozási kérelmet küldve a delikvensnek. Alapértelmezetten be van kapcsolva az engedélyezési igény kérése, de házirendből ezt meg is tudjuk változtatni – erről kicsit később.

A következő jó hír az, hogy bár eddig nem lehetett a RemoteApp munkameneteket ily módon kezelni, az R2 verzióban ez is javításra került. Mostantól a publikált alkalmazások felhasználói ugyanígy látszanak a listában, s esetükben is alkalmazhatjuk a távsegítséget. Ilyenkor természetesen mi fekete hátterű asztalt látunk, hiszen a felhasználó munkamenetének nincs asztala – de az alkalmazásokat ugyanúgy tudjuk távvezérelni.

A parancssori eszközök terén szintén történt némi javulás. Windows 2008/R2 esetén a Shadow utasítás segített átvenni egy munkamenetet, de mostantól amelyik gépen telepítve van legalább 8.1-es verzióval rendelkező RDC (elődeiről itt írtam), ugyanezen cél elérésére használható a /shadow paraméter. Előbb érdemes lekérdezni az aktuális munkameneteket (Get-RDUserSession, vagy a 2008 R2 óta létező QWinsta /Server:ServerName), majd a

mstsc /v:<ServerName> /shadow:<SessionID>

utasítással csatlakozunk a munkamenethez. A hozzáférés módja ugyanaz, mint a grafikus felületen, alapból itt is „View” módban történik a csatlakozás. Ha a vezérlést is szeretnénk átvenni, akkor a /control paramétert is hozzá kell tegyük, ha pedig át akarunk lépni a hitelesítési procedurán (és házirendből is engedélyezve van!), akkor a /NoConsentPrompt paramétert.

Nézzük a jogosultságokat. Mint már említettem, alapértelmezetten be van kapcsolva a felhasználó jóváhagyásának igénye, bármelyik módban is csatlakoznánk (megnézni/vezérelni). Ezt házirendből tudjuk szabályozni, akár számítógép-, akár felhasználói ágon:

Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Connections\Set rules for remote control of Remote Desktop Services user sessions

Ha itt kikapcsoljuk a jóváhagyást, akkor nem kell megvárni a használt munkaállomásokra való csatlakozástól megszokott 30 másodpercet sem – viszont azokkal ellentétben, amennyiben a felhasználó nem nyom semmilyen gombra, a csatlakozás eldobásra kerül.

Amit még fontos tudni, hogy csak rendszergazda csoporttagsággal rendelkező fiókok tudnak munkamenethez csatlakozni, ez nem delegálható. A másik érdekesség, hogy a cikkben leírtak nem támogatottak munkacsoportos működés esetén.

* Windows 2008/R2 segítségével tudunk ugyan trükközni, de nem lesz teljes értékű a szolgáltatás, pl. pont a cikkben említett távsegítség nem fog működni, ”Access Denied” hibaüzenetet fogunk kapni. Amennyiben ez utóbbira nincs is szükség, akkor meg lehet próbálni az itt leírt módszert.

Fontos, hogy ne is próbáljuk meg pl. Windows 2003-ről indítani a kérést, különben még csúnyább hibaüzenetet kapunk:

Session (ID ##) remote control failed

(Error 31 – A device attached to the system is not functioning.)

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 🙂

Nyomtatók kezelése v4 módra

december 8, 2014 1 hozzászólás

Egyik oktatáson* felmerült a kérdés, hogy mi is van a v4 típusú nyomtatómeghajtókkal. Utoljára ebben a cikkben említettük a verziókat, ott a v2, v3, illetve a meghajtó-izolációkkal fejeztük be.

Az összehasonlításhoz térjünk picit vissza az eddigi alapokhoz. A v3 modell elég erősen a gyártóra támaszkodik, arra, hogy minden egyes készülékhez elkészítse azokat a meghajtókat, amelyek kiaknázzák az eszköz teljes tudását (beleértve a speciális képességeket is). Előbbiek közvetlen következménye az, hogy v3-as meghajtókkal a rendszergazdák egy csomó meghajtót kell kezeljenek, szervereken és munkaállomásokon egyaránt, mindezt megspékelve 32- és 64-bites vegyes környezet esetén. Bár az utóbbi időben elkezdtek terjedni az „univerzális” meghajtók, ez még nem volt megoldás minden problémára, például arra, hogy Arm-os környezetben nem támogatott a v3 meghajtó.

Így jön képbe a Windows 8/2012-ben bevezetett v4 meghajtó-típus, ami néhány problémára gyógyírt jelenthet, cserébe bizonyos megkötésekkel kell szembenézzünk, például a GPP esetén a TCP/Ip nyomtatók nem támogatják a v4-et, valamint az LPR/LPD protokoll elavult státuszba került.

A v4 modell bevezet néhány új, egyszerű, de rugalmas szolgáltatást:

– nyomtató-megosztáshoz nem kell telepíteni a kliens-architektúrának megfelelő meghajtókat

– meghajtó állományok egymástól teljesen izoláltak, ezáltal kiküszöbölve az azonos nevű állomány-ütközéseket

– egy meghajtó nem csak egy készüléket, hanem többet is képes támogatni/kiszolgálni

– a meghajtók általában méretben is kisebbek a v3 meghajtóknál, valamint a telepítésük is gyorsabban valósul meg.

A v4 meghajtó modellek lehetővé teszik, hogy a gyártók ún. Print Class Drivers meghajtókat hozzanak létre (a Model Specific Drivers mellett), amelyek az ugyanolyan nyomtatási-nyelvű eszközökre (PCL, PS, XPS) általánosan érvényesek. Ez a csoportosítás lehetővé teszi, hogy a rendszergazdáknak kevesebb meghajtót kelljen kezelnie, ezzel a biztonságot, kompatibilitást, szervizelhetőséget és megbízhatóságot is javítja. Ráadásként ezek a meghajtók a Windows update/WSUS-on keresztül is frissíthetőek – ugyanakkor a nyomtató-szerver nem fogja kitolni őket a kliensekre.

De akkor nézzük, hogy miként is működik a megosztott nyomtatás.

A kiszolgáló rendelkezik az eszköz konfigurációjával és képességeivel, ezt kipublikálja a kliens felé, aki ezt anélkül tudja használni, hogy eszköz-specifikus meghajtót kelljen telepíteni: a kliensek a Point and Print meghajtókat használják, ezzel állítják elő a meghajtó-független nyomtatásokat. Ezáltal az új v4 típusú meghajtó-modell esetén a nyomtató-kiszolgáló nem válik disztribúciós ponttá, akitől le lehessen tölteni a meghajtót (az előző verziók a kiszolgálótól töltötték le az eszköz-meghajtót), hiszen mostantól a bővített Point and Print segítségével tudunk nyomtatni. Természetesen a régebbi (pl. Win7) rendszerű gépek kapnak egy meghajtót (lásd alább), de ez a kompatibilitás miatt van. Az új, Win8 rendszerű gépek már beépített, bővített Point and Print támogatással bírnak – ugyanakkor hagyományos Point and Print módszert is tudnak használni. Továbbá nem tiltja senki, hogy eszköz-specifikus v4 meghajtót telepítsünk a Win8 kliensre, amennyiben további képességet vagy funkciót akarunk kihasználni, pl. a múltkor már említett CSR-t.

A fentiekből következik, hogy a nyomtató-megosztások esetén van 3 nagy terület, ami változott:

  • bővített Point and Print kompatibilis meghajtó: a Win2012 egy bővített Point and Print kompatibilis meghajtót biztosít a korábbi Windows rendszerek részére, ezáltal bizonyos korábbi kliensek is csatlakozhatnak v4 nyomtatási megosztásokra. Ez konkrétan egy v3 típusú meghajtó, amely a Vista és Win7 OS-ket támogatja (bár kifejezetten szerver-oldalon nincs szűrés, a meghajtó a telepítése során ellenőrzi az alatta futó OS-t).
  • driver megosztás letiltása: az előbb említett bővített Point and Print kompatibilis meghajtót kivéve, a Win2012 nem fogja teríteni a v4 meghajtókat. A v3 meghajtók esetén semmi nem változik, a kiszolgáló a korábbi rendszerekhez hasonlóan viselkedik.
  • bővített Point and Print: ahhoz, hogy a Win8 kliensek tudjanak csatlakozni egy v4 nyomtatási megosztáshoz, beépítetten kapnak egy megfelelő meghajtót, a konfigurációs beállítások szerverrel történő szinkronizációjára.

Aki még részletesebben bele akar mászni, az kezdheti itt.

* bár szeretek oktatni, ez leginkább a blogírás rovására megy – de legalább használom a tanári képesítésem 😉

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…

Cisco VPN vs Win 8.1

szeptember 5, 2014 Hozzászólás

Az itt már említett kliensen elérkezett a pillanat, hogy Win 8-ról 8.1-re térjenek. Tekintettel arra, hogy Ent verzióról van szó, ez nem a Store-ból történő frissítés telepítése, hanem a régimódi „in-place upgrade”-nek megfelelő folyamat: azonos nyelv, azonos bit-verzió – de csont nélkül lement.

Az első nagyobb gubanc akkor jött elő, amikor VPN-t akart használni, egy Cisco VPN-t használó hálózathoz. Azt érdemes tudni, hogy a „hagyományos” VPN-kliens már elérte életciklusa végét, így az új, AnyConnect kliensre való áttérés a javasolt. Igen ám, de ehhez fogadó-oldali módosítás is szükséges, ami jelen esetben nem járható út – maradt a kerülő-megoldás.

Első körben, ha valaki figyelmesen megnézi az eszközkezelőt egy ilyen frissítés után, bizony látni fog egy csomó felkiáltójeles eszközt a hálózati csatlakozóknál. Ezek a „Deterministic Network Enhancer” csatolók, amelyek minden hálózati csatlakozáshoz létrejönnek, „eltüntetésükre” érdemes telepíteni a DNE-frissítést (32-bit, 64-bit).

A következő lépés egy megfelelő Cisco-VPN kliens telepítése (ha esetleg régebbi verzió van), ez jelen esetben egy 5.0.07.0410 (32-bit), 5.0.07.0440 (64-bit) esetén.

Az utolsó lépés egy registry-módosítás. Ehhez menjünk a

HKLM\SYSTEM\CurrentControlSet\Services\CVirtA

kulcshoz, s ott a DisplayName értéket módosítsuk úgy, hogy az elejéről levágjuk a „@oem8.inf,%CVirtA_Desc%;-t, ezáltal „Cisco Systems VPN Adapter” vagy „Cisco Systems VPN Adapter for 64-bit Windows” maradjon.

Ezek után nem maradt más hátra, mint csatlakozni és örülni 🙂

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

Miért nem csatlakozik a Wifi?

augusztus 15, 2014 3 hozzászólás

Egy laptopon operációs-rendszer frissítés történt, az eddig használt Windows 7 helyét az újabb verzió vette át. A folyamat nagyjából gond nélkül lezajlott (volt néhány alkalmazás, amelyek eltávolítása kötelező jellegű volt, néhányat a frissítés után újra kellett telepíteni), az aggodalom (működni fog-e) nagyjából 4 óra eltelte után szűnt meg, amikor lehetett végre egér-billentyűt használni. Igen, egy „szűz” 20-30 perces telepítéshez képest rémálom, viszont az alkalmazások, beállítások – s főleg a kimondott igény miatt – ezt az utat kellett követni.

A frissítés után következett az ellenőrzés, amelynek során a gép felhasználója arra panaszkodott, hogy újraindítás után minden alkalommal kézi módon kell csatlakozzon a vezeték nélküli hálózathoz, annak ellenére, hogy jó a jelszó, sőt, bepipálta az automatikus csatlakozást is. Utánajárva a problémának, kiderült, hogy a hordozható eszköznek mindkét hálózati csatolóját használta: a vezetékes és a vezeték nélkülit is – egyszerre.

A megoldáshoz szükséges tudni, hogy a Windows 8 esetén van egy beállítás, amely alapértelmezetten megakadályozza, hogy egyszerre több kapcsolatot létesítsünk akár a tartománnyal, akár az internet felé. Amennyiben tehát a vezetékes kapcsolat csatlakozott állapotban van, a wifi már nem csatlakozik (már felépült állapotban bontja a wifi-kapcsolatot), általában az előbbi ugyanis nagyobb áteresztő-képességű. Természetesen kézzel felül lehet bírálni ezt az elképzelést – ezért működött a kézi csatlakozás.

Előbbi ismeretében már „csak” engedélyezni kell az egyidejű kapcsolatokat (az alapértelmezett tiltás tiltásával), s máris vidám mosolyt látunk a felhasználó arcán. Ezt vagy házirendben (akár helyi, akár csoport-) tudjuk megoldani:

Computer / Admin templates / Network / Windows Connection Manager / Minimize the number of simultaneous connections…

vagy registry-beállítással tudjuk szabályozni:

HKLM\Software\Policies\Microsoft\Windows\WcmSvc\GroupPolicy kulcs alatt fMinimizeConnections duplaszó létrehozással.

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