Unicode XML

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 😊

Outlook form kiszórása

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.

Törölhetetlen állomány

Adott helyen abban kérték a segítségem, hogy egy adott állományt szerettek volna törölni. Természetesen, ha a szokásos módszer működött volna, nem született volna meg e cikk 😊

Ellenőrizve az alapokat, a jogosultság rendben volt, de valóban, emelt szinten sem lehetett törölni:

Parancssorból történő törlési kísérletnél:

The system cannot find the file specified.

A megoldáshoz maradjunk a régi, jól ismert DOS-os parancsnál, egy kicsit megspékelve (nem, nincs elírva, 1 idézőjel kell, s az útvonalban lehetnek szóközök is, illetve csatolt meghajtóra is működik):

del /F “\\?\Z:\mappa1\mappa 2 szokozzel akar\allomany neve

A konkrét esetben valahogy úgy sikerült létrehozniuk egy állományt, hogy az állomány neve ponttal végződött (kiterjesztés nélkül), ezért természetesen ezt is ki kellett írni a parancs sikeres végrehajtásához.

MAPI “unspecified error”

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 😊

Újabb szög a Windows 2003 koporsójába

A rendszergazda kollégák tudják, hogy egy vérbeli IT szaki nagyon ritkán van “kikapcsolt” állapotban – főleg abban az esetben, ha több rendszer is van a felügyelete/támogatása alatt. Sőt, továbbmegyek: mivel az informatikusok akkor dolgoznak, amikor a többiek pihennek (nem igazán lehet karbantartást végezni, miközben a kollégák végzik a munkájukat), a hosszú hétvége remek alkalom a teendők végrehajtására (pl. a végre kijött 1803 tesztelésére 😉 ).

Ennek fényében nem csodálkoztam, amikor egyik helyen a kollégák “megnyomták a piros gombot”: szerették volna a kezük alá tartozó rendszereket frissíteni, viszont adott cégnél meglepődve tapasztalták, hogy a Windows 2003 R2-re alapuló WSUS kiszolgáló március 30-án reggel még sikeresen, délután már sikertelenül csatlakozott a MS Update szerverekhez – s azóta folyamatosan sikertelen volt.

A hibaüzenet nem volt teljesen egyértelmű:

WebException: The underlying connection was closed: An unexpected error occurred on a send. —> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. at System.Web.Services.Protocols.WebClientProtocol.GetWebResponse(WebRequest request)

Igaz, hogy az MS saját leírásaiban sem teljesen következetes a WSUS működéséhez szükséges, tűzfalon kiengedendő portokat és célokat tekintve, a tapasztalat azt mutatja, hogy a sima http protokoll nem elég, szükséges a https is – itt viszont egy csavar kerül a történetbe, ami magyarázatot adhat a probléma gyökerére.

A https esetén nem csak a tanúsítvány állapotára kell figyelni, hanem a használt protokollra is. Nos, a Windows 2003 elég régi termék, csak az 1995-ben megjelent SSLv2, az 1996-os SSLv3, illetve az 1999-es SSLv3.1/IETF-féle TLS 1.0-t támogatja (a 2006-os TLS 1.1 és újabbakat nem). Nos, eredetileg 2018 június 30.-ra volt tervezve a régi protokollok kivezetése és a TLS1.1 alappá tétele, de ezt előbbre hozták, április 30.-ra. Fentiek fényében a WSUS azóta új frissítéseket nem tölt le, megoldás vagy egy proxy lehet, vagy természetesen egy korszerűbb rendszer.

Megj: bármikor nyitott vagyok privátban megvitatni azt, hogy valaki miért használ még elavult rendszereket, de itt szakmailag tárgyalom a témát…

VPN-kapcsolat vs. hitelesítés

Egyik cégnél az ügyvezetőnél laptop-csere történt, a régi gép helyett egy Windows 10-el ellátott készülék került az asztalára. Haladóbb felhasználó révén ő maga akarta “belakni” a gépet, többek között a VPN-kapcsolat létrehozását is ő vállalta magára.

A kapcsolat létrehozásával nem is volt gond, de a csatlakozás nem akart létrejönni, hibával eldobta:

Ezzel nem tudott mit kezdeni, így segítséget kért. Ha átnézzük a VPN kapcsolat tulajdonságait, láthatjuk, hogy mi a hiba: a hitelesítési módszer nincs kiválasztva (megjegyzem, ez nem csak Win10 esetén van így*).

Ha picit jobban belemélyedünk, akkor kiderül, hogy bár látszólag semmi nincs kiválasztva, a szerver logjaiból egyértelművé válik, hogy EAP hitelesítéssel próbálkozik. Mivel esetében nem ez volt a választott hitelesítés, így az alsó “pötty” kiválasztásával, MS-Chapv2 segítségével máris csont nélkül tudott csatlakozni.

*: Amennyiben EAP hitelesítés van a szerveren is, csatlakozik, s automatikusan kiválasztásra is kerül ez a protokoll

SMB1 és NAS

JoeP-nek a múltkori problémája után egy másik helyen szintén jelentkezett a jelenség; egy kolléga segítséget kért, jelezve, hogy pingetni tudja a NAS-t, de intézőben nem dob fel semmit, helyette ezt kapja:

Mivel sejtettem, hogy ugyanarról a problémáról van szó, kértem, hogy előbb járjuk körbe a kérdést, így az alábbi képernyőmentéseket kaptuk:

• egy már létező csatolás megnyitásakor a következő ablak nyílik meg:

• új csatolás létrehozásakor megbizonyosodtunk, hogy valóban az SMB1 hiánya okozza a problémát:

A fentiek alapján egyértelmű volt a lehetséges megoldás (engedélyezni az SMB1 protkollt a Windows 10 kliensen, ami egy kötelező újraindítást igényel), de egy dolog szöget ütött a fejembe: nála a NAS egy Synology, ami viszont nem csak SMB1-et tud. Ezt jeleztem neki, majd közösen megnéztük a DSM beállításait. Valószínűleg abból adódóan, hogy a Synology elég régóta megvan neki, s csak a verziókat frissítette az eszközön, a minimális és maximálisan engedélyezett protokoll az SMB1 volt (File Services / SMB / Advanced Settings). Amint feltoltuk SMB3-ra, máris kikerültük az eredeti problémát, íme a “köztes” állapot, amikor már működik, de SMB1 még nincs kikapcsolva:

S hogy honnan tudjuk, hogy jól dolgoztunk? Egyrészt például tudunk csatlakozni 😊 Másrészt viszont ellenőrizzük a kapcsolatokat, a Get-SMBConnection utasítással:

A végére jönne az elméleti rész, de ezt (a cikk végén egy hasznos MS-linkkel) már körbejártam a múltkor ebben az írásomban, így nem akarom ismételni magam 😊