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 😊

Néhány aktivációs eszköz

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