Send connector gondolatok
Bár mostanában kicsit el vagyok havazva néhány nagyobb migrációval, egy-két apró segítségkérés megoldását próbálom beszorítani az időmbe.
Egyik helyen kértek, hogy nézzem át a levelezés beállításait, ugyanis egy redundánsra elképzelt környezetben pont a redundancia hiányzott – konkrétan sem a levélküldés, sem a levélfogadás nem működött, külső partnerek irányába. A DAG működött, tehát a kliensek tudtak csatlakozni a postafiókhoz, belső levélküldés rendben volt, de szerették volna, ha valóban magas rendelkezésre állást alakítunk ki.
A fogadás témakörét néhány alapbeállítás hiánya (másodlagos MX, tűzfal-beállítás) kimerítette, a küldésnél viszont akár ennek, de leginkább ennek a cikknek az olvasása hiányzott. Létezett ugyan két Send connector, mindegyiknél a “Source” szervereknél ki volt töltve az elképzelt konfiguráció alapján – ettől függetlenül, amikor az elsődleges kiszolgálót leállítottuk, a küldés továbbra is az “ő” küldési csatlakozóján akart kimenni. Természetesen a kiszolgáló leállított állapotában az sem tud küldeni, így a levelek csak gyűltek – az ügyfél és a kollégák pedig értetlenkedtek.
A megoldást többféle módon próbálták megtalálni, ezekből szemezek.
Egyrészt, minden csatlakozón kipróbálták a “Scoped send connector” bekapcsolását. Nos, ez valóban az egyik helyes megoldás, bizonyos feltételekkel: amennyiben a tartományban ki vannak alakítva telephelyek, megfelelő ip-címtartománnyal, s a levelező-kiszolgálók különböző telephelyek tagjai. Ebben az esetben ugyanis csak a saját telephely (és a “Scope” által nem védett) küldési csatlakozóit látja a kiszolgáló, nem fogja használni a “másik” csatlakozóját. Jelen esetben nem volt telephelyes kialakítás, így ennek a pipának a ki/be kapcsolt állapota semmit nem jelentett.
A másik próbálkozás a súlyozásra (költség) irányult. Nos, itt hivatkozok vissza az előbbi cikkre – ugyanis tekintettel arra, hogy a fő telephelyhez elképzelt csatlakozó költsége kisebb volt, mint a második telephelyé, mindig ő lett a kiválasztott. Az, hogy a kiszolgáló épp nem működött, nem zavarta az Exchange-t… Amint egyenlő költséget állítottunk be, a kiválasztási folyamat továbblépett, lehetővé téve a második kiszolgáló csatlakozójának használatát.
Egy másik megoldás, amit mondjuk nem próbáltak, az MX-rekordok alapján történő küldés (ez ugye akkor járható, ha nem DNS-alapú címkeresés történik, hanem smart host-nak küldik). Ekkor felvesszük minkét smart-hostot 1-1 A rekordba, majd azonos névvel, de különböző súlyozással felvesszük a két MX rekordot (egyik mutat egyik A rekordra, másik a másikra).
A megoldások sora tovább folytatódhat, de gondolatébresztőnek ennyi elég…
Hangfelolvasás (Text-To-Speech)
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…
Minimális keresési karakterszám a GAL-ban
Adott helyen egy olyan probléma merült fel, hogy „régebben” jól működött az Exchange címtárban a keresés, viszont egy ideje nem megy. Pontosítva a megfogalmazást, kiderült, hogy azokra készülékekre vonatkozott a megállapítás, amelyek ActiveSync-et használnak.
Körbejárva a kérdést, a háttérben az van, hogy Exch 2007-től alapértelmezetten 4 karakter alatt nem megy a keresés a GAL-ban. Ez Exch 2003-ban még 2 karakter volt, tehát ez egy új „feature”, nem bug 😊
Szerencsére ez módosítható: http://terenceluk.blogspot.com/2013/12/unable-to-search-gal-with-less-than-4.html
Hyper-V VM-ek vCPU
Bár utána lehet nézni a neten, egyik kolléga tőlem kérdezte meg, hogy „Egy Hoston lévő fizikai processzor magok számánál, lehet-e több magot kiosztani a vm-ek közt?”
Nos, a válasz* nem egyszerű igen vagy nem, hanem attól függ (s itt jöhetne egy kétopciós válasz (2016 előtt és után), de kicsit menjünk részleteibe).
Kezdjük a szerver oprendszerű gazdagépekkel. Ha Windows 2008/R2 fut a host-on, akkor a Microsoft által támogatott vCPU-k száma 4 (azért ez a megfogalmazás, mert technikailag megoldható ennek a határnak az átlépése, de az már nem lesz támogatott).
Ha 2012/R2 a gazdagép, akkor már képbe jön a vendég-gép oprendszere is (szerencsére a 2012 R2 esetén megjelenő Gen2 még nem), ideális esetben számolhatunk 64-el – de max a logikai processzorok száma (Logical processors = Sockets * Cores * HyperThreading).
Ha 2016 vagy 2019-ről beszélünk, akkor még bonyolultabb a válasz, ugyanis képbe jön a VM generációja, illetve a vendég OS fajtája: korszerű OS esetén (2016, 2019) G1 VM-nél 64 vCPU, G2 VM-nél 240 vCPU-ig tornászható fel a szám (még ha fizikailag nincs is annyi, de ez – a méretezés – már egy másik téma). Amennyiben 2012 R2, 2012 vagy 2008 R2-nk van, akkor egységesen 64 vCPU a limit, „sima” 2008 esetén pedig max 8.
Amennyiben Windows 10-es host-ról van szó, akkor kicsit változhatnak a számok.
* Ismerve a kollégát, értettem a kérdését is – ugyanis lehet méretezésre is gondolni, de ő most konkrétan nem azt akarta kérdezni 🙂
Exchange 2019 morgás
Ugye a napokban lett véglegesítve az Exchange 2019. Eddig még lehetett reménykedni, hogy az előzetes információkkal ellentétben még van esélyünk a cikket kiváltó morgás megszűnésére, de a remény elhalt… Ugyanis szép és jó a fejlesztés, de egy dolgot emelnék csak ki belőle: a Mailbox kiszolgáló minimálisan ajánlott 128 GB memóriáját. Az MS-nél vagy nagyon elgurult a gyógyszer, vagy ezzel akarják a kkv-kat az Office365 irányába terelni.
Egyik érintett kis cég, ahol a napokban beszéltünk fejlesztésről, kapásból kilőtte ezt a verziót. Mivel vidék, rossz internet-eléréssel, ráadásul nagyon (értsd: nagyon) kis költségvetésű cég, az O365 is kilőve – így maradtunk az Exchange 2016 bevezetésénél.
Aki ismer, tudja, hogy amennyire lehet, MS-párti vagyok, ugyanakkor szakmai szempontból is meg szoktam mondani a véleményem – ennek kapcsán ez a lépés több fekete ponttal felérő minősítést ér… Csak ismétlésként, az eddigi minimális követelmények:
– Exchange 2019: 128 GB
– Exchange 2013, 2016: 8 GB
– Exchange 2010: 4 GB
ManagedBy attribútum
Egyik kolléga azt a kérdést szegezte nekem, hogy egy számítógép AD-fiók ManagedBy attribútuma felhasználható-e arra, hogy egy felhasználót az adott géphez kötni, pl. leltár esetén egy leltári számmal elnevezett gép tulajdonosa visszakereshető legyen.
Ez nem egy gyakran használt tulajdonság, így a pozitív válasz mellé elküldtem neki a részleteket is, viszont úgy gondoltam, érdemes ide is archiválnom.
Csoportok esetén ez a tulajdonság szinte értelemszerű, hiszen amennyiben beállítjuk az attribútum értékét és bekapcsoljuk a pipát, úgy a háttérben az adott csoport Security fülén megjelenik a „manager” és írás-jogot kap a csoporttagság módosítására.
Egy másik felhasználása az RODC-k esetén jön képbe, ugyanis ezzel tudjuk rajtuk a helyi adminisztratív fiókokat szabályozni (pl. „RODC-admins” nevű csoport), valamint a RepairAdmin értéke is ez lesz.
