Archívum

Archive for the ‘General’ Category

Egy apró „fejlődési” hiányosság

május 30, 2019 1 hozzászólás

Nemrég egy sérült AD-t kellett rendbetennem. Most nem térek ki, hogy a két sérült AD-partíció javítása sem volt egyszerű (az külön megérne egy cikket), helyette az AD-hoz tartozó file-replikációt veszem górcső alá.

Aki még nem foglalkozott vele, annak kezdem az elejével. A tartományvezérlők a feladatuk elvégzése során elég sok feladatot kezelnek – pl. tudjuk, hogy az egész AD egy jó, működőképes DNS nélkül nem ér semmit. No de a DNS nem minden. Ritkán, de előfordul, hogy maga az AD-adatbázis sérül meg (ez tartalmazza a partíciókat), illetve még egy fontos része van: a házirendeket és scripteket tartalmazó Sysvol mappa replikációja.

Ez a replikáció két módon történhet. Egyrészt van a régi, “hagyományos” NT-korszakbeli LAN Manager Replication Service-t váltó FRS (File Replication Service), másrészt az új, 2003 R2-ben bevezetett, de 2008-ban kiteljesedő DFSR (DFS Replication). Manapság, ha új tartományt építünk, alapértelmezés szerint ez utóbbi lesz használva, de régebbről “görgetett” tartományok esetén is tudunk váltani (ehhez minimum 2008-as tartományi-szint szükséges). Sőt, Windows Server 2016 RS3 (1709)-től már az FRS egyáltalán nem támogatott.

Az áttérés nem nehéz, arra érdemes figyelnünk, hogy mindig legyen szinkronban a tartományunk (amennyiben egyik DC nem értesül adott áttérési műveletről, utólag megpróbálja “utolérni” a többieket – akkor van gond, ha bármilyen hiba bekövetkezik).

Visszatérve, a jelzett helyen elég gáz helyzet volt. Mivel nem akartam/akarták a teljes AD-t újrahúzni (jogosan), a már említett adatbázis javítása után következett a replikáció helyretétele. Igen ám, de ekkor derült ki, hogy még FRS-t használnak, így ezt a vonalat elengedve, az a döntés született, hogy akkor most térünk át DFSR-re. Általánosságban a javaslat az, hogy előbb a hibákat hárítsuk el, s egy egészséges környezetben változtassunk – de jelenlegi helyzet egyike a ritka kivételeknek, ahol ezt könnyebb volt meglépni.

A két replikációs módszer összehasonlítását már megtette más – én arra próbálok mindenkit rávenni, hogy egy hozott/kapott, de akár saját “görgetett” tartomány esetén is, amennyiben lehetséges, lépje meg ezt a lépést. Erre utal a cím is, hogy a cég fejlődik, az AD séma változik – de tervezzük bele a replikáció váltását is, egy hibakeresés esetén saját magunk munkáját is megkönnyítve 😉

Egy rossz tervezés

április 25, 2019 Hozzászólás

Mivel máshol is belefutottam, gondoltam leírom, hátha van, aki legalább ezt olvasva észbe kap… Volt egy projekt, amelyben a segítségem kérték, egy teljes migrációt kellett végrehajtani a régi szerverekről az újakra. A kliens ugyanakkor nem minden fázist adott át, többek között a mentést és annak beállítását házon belül tervezte megoldani.

A sikeres migráció végéig még mindig nem döntötték el, hogy milyen módszerrel, milyen adattárolóra, milyen rendszerességgel fog történni a mentés. Abban egyetértettünk, hogy ez mindenképp szükséges, de mivel továbbra is saját maguk akarták kivitelezni, nem erőltettem a dolgot.

Szerencsére most nem azzal folytatom, hogy egy kripto-vírusos támadás után nem volt hova nyúlni. Viszont egy másik dolog következett be: a levelező-kiszolgálónak szánt lemezek teltek meg. Az előre egyeztetett elképzelés szerint nem körkörös loggolást használnak (ha lehet, amúgy sem ez a javasolt), ez viszont azzal jár, hogy ha nincs teljes mentés (s itt külön cikk lehetne a mentések típusairól, a piacon található mentőszoftverek módszereinek elnevezéséről), akkor a naplók csak gyűlnek. Ha nem monitorozzuk (akár külön szoftverrel, ami riaszt, akár manuálisan), az emailezési szokásoktól függően elég hamar meg tudják tölteni a rendelkezésre álló területet – amikor is a levelezés megáll. Vannak ugyan beépített korlátok az Exchange-ben, hogy bizonyos szint alá ne engedje megtelni a lemezt, de ezen korlátok elérésekor is lehetnek kellemetlenségeink az email-forgalomban. Helyette a javaslat az, hogy minden esetben tervezzük meg a mentést is (adott cégnél “csak” a levelezés állt le, mert az adatoknak, adatbázisoknak volt elég hely – de azok mentése is szükséges!).

Sajnos még mindig nem mindenhol fordítanak kellő figyelmet a mentésekre. Lehetne azt mondani, hogy cégmérettől függ – de nem igaz. Egy kis cégnél is láttam helyesen beállított mentést – ez a (magyarországi viszonylatban) közepes cég viszont nem rendelkezett ilyennel. Amikor felhívtak, hogy nem megy a levelezés, s megtaláltuk a “hiba” okát, fokozottan jeleztem nekik, hogy ez miből eredt, újból megígérték, hogy beállítják a mentést – majd bizonyos idő múlva, amikor ismét megkerestek, ugyanezzel a problémával, akkor már szerencsére hajlottak rá, hogy közösen átbeszéljük és kivitelezzük a végleges megoldást.

WinRM nem megy

február 14, 2019 8 hozzászólás

Adott helyről azzal kerestek meg, hogy egy Win2012R2-n nem működik a WinRM. Ez onnan látszott, hogy egy másik gépről, ServerManagerből nem tudott csatlakozni, azt írta, hogy “Online – Verify WinRM3.0 service is installed, running, and required firewall ports are open“.

Tudjuk, hogy alapból ez az oprendszer elég jól fel van készítve a távoli csatlakozásra, ezért nem igazán értettem a dolgot. Ellenőriztük a WinRM szervízt – fut. .Net komponensek – telepítve. WMF verzió, ami ugye szorosan kötődik a PS verzióhoz ($PSVersionTable.PSVersion) stimmel. Listener lekérdezés:

winrm e winrm/config/listener

eredménye pipa, a kért 5985 porton hallgat. Tűzfal kivétel: pipa.

Szóval az alapok átfutva, minden rendben levőnek tűnik. Akkor kicsit menjünk mélyebbre.

Tudjuk, hogy az “elindítás” miként szokott történni: a winrm qc (=QuickConfig) parancssal. Ez mit is csinál? Röviden, az alábbi parancsokkal tudnánk leírni a működését:

sc config “WinRM” start= auto

net start WinRM

winrm create winrm/config/listener?Address=*+Transport=HTTP

netsh firewall add portopening TCP 80 “Windows Remote Management”

Rendben, tehát ha töröljük a listenert, s ismét létrehozzuk, akkor nem lehet gond. (Listener törlés: winrm delete winrm/config/Listener?Address=*+Transport=HTTP)

A törlés után ismét létrehozva valamelyik módszerrel (akár winrm qc, akár winrm create… verzióban) továbbra sem változott semmi.

Futtattam egy

Test-WSMan -ComputerName GépNév

parancsot – szintén hibára futott, teledobta pirossal a képernyőt.

Akkor nézzük magát a kapcsolatot, illetve a nyitott portot. Amikor lokálisan kipróbáltuk, akkor csont nélkül tudott csatlakozni a kérdéses porthoz, távolról már nem (a telnet is alkalmas lehet, de ez “beépített”):

Test-NetConnection localhost -port 5985

Ekkor már kezdtem gyanakodni, hogy valahol itt lehet a kutya elásva. Lefuttatva egy

netstat -ano | findstr 5985

lekérdezést, kiderült a turpiság: valamiért csak a 127.0.0.1-en hallgatott a WinRM szolgáltatás, a helyes 0.0.0.0 helyett. Ezt megerősítette a

netsh http show iplisten

parancs is, így nem maradt más hátra, mint

netsh http delete iplisten 127.0.0.1

futtatása, ami után helyreállt a béke. S hogy miért volt ez? Valószínűleg egy bug lehet, ami bizonyos esetekben ilyen eredményt produkál…

Hangfelolvasás (Text-To-Speech)

január 7, 2019 2 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…

ManagedBy attribútum

október 19, 2018 Hozzászólás

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.

 

Kategóriák:General, Windows Server Címke:

Unicode XML

szeptember 26, 2018 Hozzászólás

Nemrég abban kérték a segítségem, hogy egy PowerShell script segítségével készített xml állomány kódolását miként lehet megváltoztatni, ugyanis azt eredetileg UTF8-ban mentették le, nekik ez viszont nem felelt meg.

Amennyiben (mint jelen esetben) egy már létező adattal dolgozunk, az alábbi példában a $XML változóban hivatkozok rá, ha viszont még nincs, akkor pl. az alábbi utasítással hozhatjuk létre:

$XML = New-Object System.Xml.XmlDocument

A kódolás változtatására a neten keresgélve több módszert is találhatunk. Ezekből próbáltam egyet megfelelően összeállítani, amely még ha nem is működik minden esetben, de az adott cél elérésében segített (az adott sorba mindenki másolja a neki megfelelő kódolást). Amit viszont “csak” dokumentáltam, hogy a különböző Unicode kódolások eléréséhez milyen paramétereket kell megadni – ez azért fontos, mert van olyan kódolás, ahova 1, van, ahol 2 paramétert kell kötelező módon megadni (minden esetben a BOM az utolsó paraméter):

# Encoding types, just for listing

# UTF8

$UTF8WithoutBom = New-Object System.Text.UTF8Encoding($false)

$UTF8WithBom = New-Object System.Text.UTF8Encoding($true)

# UTF16

$UnicodeLEWithoutBOM = New-Object System.Text.UnicodeEncoding($false,$false)

$UnicodeLEWithBOM = New-Object System.Text.UnicodeEncoding($false,$true)

$UnicodeBEWithoutBOM = New-Object System.Text.UnicodeEncoding($true,$false)

$UnicodeBEWithBOM = New-Object System.Text.UnicodeEncoding($true,$true)

# UTF32

$UTF32LEWithoutBOM = New-Object System.Text.UTF32Encoding($false,$false)

$UTF32LEWithBOM = New-Object System.Text.UTF32Encoding($false,$true)

$UTF32BEWithoutBOM = New-Object System.Text.UTF32Encoding($true,$false)

$UTF32BEWithBOM = New-Object System.Text.UTF32Encoding($true,$true)

# End listing

 

$FileName = “$Path\$name.xml”

$File = New-Object System.IO.StreamWriter($FileName, $false, $UnicodeLEWithoutBOM)

$XML.Save($File)

$File.Close()

Ez a része kipipálva 😊

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

Outlook form kiszórása

augusztus 17, 2018 Hozzászólás

Az előző után ismét egy Outlook-os történet. Adva van egy custom form, .fdm formátumban, amit központilag szeretnénk kiszórni. Nos, ehhez ez a formátum nem jó, át kell alakítani .oft formába. Ehhez manuálisan betöltjük az .fdm-et, engedélyezzük a Developer menüpontot, majd ezen belül a Form szerkesztésével megnyitva, Fájl, mentés másként, elmentjük.

S itt jön a csavar. Az Office 2013-ban van egy bug, ami miatt az elmentett form nem teljesen használható, ezért az Office 2010 segítségét vettük igénybe (bizonyos okok miatt 2016 nem jöhetett szóba). Ugyanazt a műveletsort elvégezve, az elkészült form már használható volt mindkét érintett verzióban, jöhetett a tömeges telepítés.

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