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.

Tanúsítványok és Windows Phone / Mobile

augusztus 1, 2016 Hozzászólás

Egy jó ideje velünk van az IKEv2 típusú VPN, amit úgy szoktunk „reklámozni”, hogy a mobilokra lett kifejlesztve, s csak „másodlagosan” számítógépre. Nos, ezzel kapcsolatban osztanék meg két apróságot, amire érdemes figyelni:

– a Windows Phone (7 – 8.1) / Mobile (10) telefonokon nem lehet törölni a tanúsítványt (létezik egy Certificates app, de az csak megtekintésre jó)

– egyes helyeken olvasható az, hogy a VPN kiszolgálón a root tanúsítványok között csak a miénk legyen, ellenkező esetben minden mást is elfogad. Nos, ez nem állja meg a helyét, hiszen nem véletlenül kell a tanúsítvány tartalmazza a „Server Authentication” és „IP Security IKE intermediate” felhasználási módokat (EKU/AppPolicies*).

* Windows 2000-ig EKU, 2003-tól Application Policies néven található meg az utód, ami viszont MS-specifikus, s bár legtöbbször használatuk megegyezik, nem ugyanaz az EKU-val.

Kategóriák:PKI Címke: ,

A lefoglalt vhd esete

július 19, 2016 7 hozzászólás

Egyik cégnél a kollégák már a hajukat tépték, amikor egy aznap délelőtt leállított virtuális gépet akartak ismét elindítani, s folyamatosan hibára futott. Az eseménynaplóban egy olyan hibaüzenetet találtunk csak:

VM-Név

Virtuális-gép-ID

VHD-útvonal.vhd

%%2147942432

0x80070020

The locale specific resource for the desired message is not present

Próbáltunk ennek alapján elindulni. A hibakód azt jelenti, hogy

2147942432: The process cannot access the file because it is being used by another process. (0x80070020).

Tehát próbáltuk kideríteni, hogy ki/mi használhatja ezt az állományt. Mivel a gép leállítása azért történt, mert egy újabb oprendszerű, de azonos nevű VM vette át a feladatát, első sorban erre gyanakodtunk – de a vhd nem volt hozzá csatolva.

Kiderült, hogy egy másik kolléga nem ezt a módszert választotta pár adat kinyeréséhez, hanem a gazdagépre csatolta fel közvetlenül a vhd állományt. Onnan leválasztva, máris elindult a virtuális gép…