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 😊

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

Hibernálási gondok laptopon

Adott helyen felmerült, hogy egy hordozható gépen be van állítva, hogy a képernyő lehajtásakor hibernálódjon, ettől függetlenül nem történik meg.

Természetesen powercfg /requests ellenőrzés mindent rendben mutatott. Ellenőrizve lett, hogy a gyártó saját energia-gazdálkodási programja nincs telepítve vagy nem annak a sablonja aktív (ellenkező esetben annak beállításait is érdemes tételesen átnézni, azok elsőbbséget élveznek a rangsorban). A Vezérlőpult/Energia-gazdálkodás esetén a baloldali menüben található opciót kiválasztva látszott, hogy a beállítás elvileg jó:

Ideiglenes megoldásként a hibernálás opciója bekerült a Start menü/Leállítás opciók közé (előző képen szintén látható), de hosszú távú megoldásra is kértek segítséget.

A végleges megoldás a megfelelő energia-használati sablon módosítása volt (itt még az eredeti, rossz értékek láthatóak):

Ezután nézzük, hogy miért is van ez így.

Nos, a megoldást ezt az MS cikk szolgáltatja.

Ennek alapján a “kinti” opciók a “preferált” energia-séma beállításait mutatják, ami természetesen nem mindig az aktív – de hogy miért nem lehet egy mozdulattal azt is állítani, amikor sémát váltunk, nem igazán értem… (feature, nem bug 😉)

A preferált sémát itt találjuk, a PreferredPlan értékben: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\explorer\ControlPanel\NameSpace\{025A5937-A6BE-4686-A844-36FE4BEC8B6D}

Szerencsére ezt meg tudjuk változtatni, ide be kell írjuk a kívánt értéket. Fontos, hogy minden séma-módosítást ezután végezzünk, ugyanis az aktuális séma értékeit fogja oda bemásolni. Ha netalán egyedi sémát hoztunk létre, annak azonosítóját a Powercfg /list lekérdezéssel tudjuk kilistázni – de mint a cikk is említi, a grafikus felületen a “Javasolt” mindig a Balanced mód lesz. 😊

Utolsó hibaként még az merült fel, hogy a jó beállítások végrehajtása után is el szokta “felejteni” a gép a helyes értéket (preferált séma maradt, csak a hibernálás váltott vissza “semmire”). Nos, szerencsére nem tartott sokáig ez az állapot, a gépet naprakész állapotba hozva a frissítés ezt is helyretette.

RDP tanúsítvány

Egy régi félkész cikket próbálok befejezni… A témát réges-rég is említettem, minimálisan, de azóta rengeteg víz lefolyt a Dunán 🙂

Nos, akkor kezdjük átismételni, mi történik, amikor RDP-vel csatlakozni próbálunk egy géphez (leírás, értékek). Első körben van egy biztonsági ellenőrzés, amelynek során a rendszer ellenőrzi a registry-ben, hogy van-e már mentett kapcsolatunk a távoli kiszolgálóhoz, s abban mit engedélyeztünk (HKCU\Software\Microsoft\Terminal Server Client\LocalDevices\<Név> – ha csak most engedélyezzük az elsőt, létrehozza a LocalDevices kulcsot is). Ennek fényében kapunk egy sárga, vagy, ha “online” csatlakozunk (nem RDP-állomány), akkor a változatosság kedvéért kék ablakot (hogy még bonyolultabb legyen, a kék ablak sem mindig pattan elénk, csak az 1, 2, 32 értékek hiányában):

 

A kék ablak (ha nem RDP-állományból, esetleg ha a LocalDevices értéke 12 (1100) – amennyiben betesszük a pipát, akkor az érték 77 (0100 1101) lesz):

Továbbjutva az első akadályon, máris egy másik registry-kulcs által szabályozott területre érünk. Ekkor a rendszer ellenőrzi a HKCU\Software\Microsoft\Terminal Server Client\Servers kulcs tartalmát, s amennyiben van, úgy alapértelmezés szerint felajánlja az itt található UsernameHint felhasználót s kéri a jelszavát. Amennyiben nincs, egy választó-ablakot dob fel, az aktuális felhasználónak kérve a jelszavát vagy lehetőséget adva másik felhasználónév/jelszó megadására. Ha van mentett jelszavunk, akkor természetesen kiolvastathatjuk a Hitelesítőadat-kezelőből is. Sikeres hitelesítés esetén megérkeztünk az aktuális témához, a második sárga ablakhoz:

Ennek megfejtése: szintén az előbb említett registry-kulcsban előfordulhat egy tanúsítvány-kivonat (hash) – ha ez érvényes, azaz megegyezik a gépen tárolt tanúsítvány lenyomatával, észrevétlenül csatlakozunk a kiszolgálóhoz – ellenkező esetben jön elő a jelzett, második sárga ablak. Ha utánajárunk az alapértelmezett, önaláírt tanúsítványnak, kiderül, hogy a számítógép tanúsítvány-tároló Remote Desktop mappájában található, így könnyen gondolhatnánk, hogy azt lecserélve hátradőlhetünk – de ez nem így van. Elkeseredésre azért nincs ok, mert azért a megoldás egyszerű: miután a “jó” tanúsítványt betesszük a számítógép tanúsítvány-tároló Personal mappájába , le kell cseréljük a WMI-ban tárolt tanúsítvány-kivonat értékét (szaknyelven a root\cimv2\TerminalServices névtér Win32_TSGeneralSetting osztály beállításaiban a SSLCertificateSHA1Hash értékét kell cserélni  ).  Visszalépni nem lehet (de minek is kellene?).

Biztos, ami biztos, előbb lekérdezzük a jelenlegi értéket:

wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Get SSLCertificateSHA1Hash

Ugyanezt az eredményt kell találjuk a grafikus felületen megnyitott tanúsítvány ujjlenyomat-értékében is (“Thumbprint”).

Szintén pl. a grafikus felület segítségével kiderítjük a számítógép “rendes” tanúsítványának lenyomatát, majd a cseréhez a következő utasítást kell végrehajtani:

wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash=”THUMBPRINT”

Vagy aki inkább Powershell-t használna (Set-WmiInstance helyett lehetne swmi, hasonlóan a Get-WmiObject helyett gwmi):

# Lekérdezzük a jelenlegi lenyomatot

$TSGeneralSetting = Get-WmiObject -class “Win32_TSGeneralSetting” -Namespace root\cimv2\terminalservices -Filter “TerminalName=’RDP-tcp'”

# A számítógép tanúsítvány-tárából kiválasztjuk az SSL-tanúsítvány lenyomatát (ha több tanúsítványunk van, akkor ellenőrizzük a kapott eredményt)

$thumb = (gci -path cert:/LocalMachine/My | select -first 1).Thumbprint

# Beállítjuk az új értéket Set-WmiInstance -Path $TSGeneralSetting.__path -argument @{SSLCertificateSHA1Hash=”$thumb”}

Ezt tovább tudjuk fokozni, hogyha más néven csatlakoztunk, további adatok lesznek a sárga ablakon:

 

Ha viszont egy olyan kiszolgálóra csatlakozunk, amelyik nem támogatja az NLA-t (például alábbi esetben Windows 2003), akkor az alábbi ablakok jönnek:

 

Huhh, elég volt a sárga ablakokból. Uff.

Házirendek csak hordozható gépekre

Adott helyen felmerült a kérdés, hogy miként lehet úgy kiszórni egy házirendet, hogy csak a hordozható eszközökre legyen érvényes.

Egyrészt természetesen maradhat a jól bevált módszer, amely szerint AD-csoportot hozunk létre, s csak arra érvényesítjük a házirendet (vagy fordítva, abba tesszük azokat a gépeket, amelyekre nem kell érvényesüljön, s „Apply group policy – Deny” opciót választunk). Ugyanakkor létezik „elegánsabb” módszer is, WMI-szűrő segítségével.

Nem fogok felsorolni minden lehetséges szűrést, ami alapján kétfelé tudjuk választani a gépeink, néhány ötletet adok csak:

1. a memória fizikai mérete alapján: tudjuk, hogy a hordozható eszközökbe SODIMM memória kerül, asztali társaikba pedig „normál” méretű DIMM. Előbbinek FormFactor értéke 12, így a szűrönk így néz ki:

Select * from Win32_PhysicalMemory WHERE (FormFactor = 12)

2. az akkumulátor jelenléte alapján (ha nincs, akkor értéke 0; bár mivel van, aki akku nélkül használja, fenntartással kezelném):

Select * from Win32_Battery WHERE (BatteryStatus <> 0)

3. ha tudjuk, hogy minden DMI adat ki van töltve (személy szerint igyekszem erre mindig figyelni), akkor a ház típusa (burkolat) alapján is lehet szűrni, az általában használt értékek itt vannak felsorolva (ebben az esetben természetesen granulárisabban tudunk szűrni):

Select * From Win32_SystemEnclosure Where ChassisTypes = “9”

p.s. régi kapcsolatommal, Tamással [Aida64 vezető fejlesztője] történt egyeztetésem kapcsán felmerült, hogy most már sok alaplap – főleg a Mini-ITX és Mini-STX kialakításúak –, valamint sok mini-PC is SO-DIMM foglalatos, így az első nem biztos, hogy teljes értékű megoldás. Viszont akinek a hálózatában ilyenek vannak, használhatja a többi (akár általam le nem írt) módszert 🙂

Hibakód szöveges értelmezése egy Win2016 ütemezett feladat kapcsán

Többször szokták tőlem kérdezni (tanfolyamokon is), hogy mi a legegyszerűbb módja egy hibakód „visszafejtésének”, azaz a hozzá tartozó szöveges hibaüzenet kiderítésének. S itt természetesen nem a „well-known” kódokról beszélek (pl. 0x80070005 Access denied) :).

Mivel kétféle módon jelenhetnek meg a hibakódok, kezdem a decimális formátummal (előtagja 0n) – ugyanis első lépésben úgyis hexává (előtagja 0x, a másik formátum) alakítjuk, s innentől már ugyanaz a menet. Tehát mit kell tudnunk, ha mondjuk egy 2147944189 számú hibaüzenetet meglátunk?

A megoldáshoz vegyünk elő egy számológépet, ami tudja a két számrendszert (Windows-on a számológépet pl. „Programozó” módba kell állítani). Kiválasztjuk a hibakód számrendszerét (decimális vagy hexadecimális), beírjuk az ismert értéket, majd megnézzük azt hexadecimális formában. Amennyiben az első négy karakter „8007”, akkor rendben vagyunk, ú.n. „Win32 Status Code” lesz a megfejtés, innentől csak a második négy karakter lesz érdekes.

Következő lépésként a második négy karaktert kell visszalakítsuk decimálissá. Ehhez a számológépbe beírjuk hexa formátumban, majd kiolvassuk decimálisban. Utolsó lépésként lefuttatjuk az alábbi parancsot, s meg is van a keresett szöveges hibaüzenet:

net helpmsg decimális_szám

Mivel az operációs rendszer nyelvén kapjuk vissza az üzenetet, a honosítások nem biztos, hogy visszaadják az eredeti értelmezést, így javaslatom szerint ezt mindenképp egy angol nyelvű gépen tegyük meg (utána könnyebb rákeresni is) – s reménykedünk benne, hogy nem visz tévútra.

S hogy miért pont ezt a konkrét hibakódot hoztam fel? Egy számomra eddig ismeretlen jelenség miatt: egy Windows 2016-on szerettem volna ütemezett feladatot beállítani, hogy egy technikai felhasználó nevében fusson – s ekkor örvendeztetett meg a rendszer a fenti kóddal. A felhasználónak volt elég joga, nem volt letiltva, nem volt zárolva – az egyedüli „hibája” az volt, hogy azon a gépen nem volt profilja (hiszen soha nem lépett be rajta). Az eddigi Windows-okon ez nem volt gond, legelső futtatásnál létrejött a profil – itt az idő szűkössége miatt leggyorsabb megoldás az volt, hogy bejelentkeztem a fiókkal, utána már csont nélkül elfogadta az ütemezett feladat hozzárendelését is.

Windows 10 és Network Level Authentication

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.”

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:

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.

Alvó szerver

Egy „legendás” „piros gombos” segítségkérés során az volt a kérdés, hogy egy Windows 2012 R2 kiszolgáló miért elérhetetlen időnként. Ráadásul egy olyan környezetben, ahol 1 kiszolgáló van, a felhasználók száma is minimális, és látszólag semmi nem indokolja a szerver leállását.

A hibakeresés szerencsére aránylag hamar feltárta az okot, az eseménynapló rengeteget segített, a System-ben ez volt:

Kernel-power 42

The system is entering sleep.

Sleep Reason: Application API

Nos, nem gyakori, hogy egy szervert elküldenek aludni. Ha meg igen, akkor lehet, hogy célszerűbb inkább leállítani, majd amikor szükséges, akkor újból indítani, nulláról betölteni – de jellemzően nem ekkora cégről beszélünk ilyen esetekben, hiszen az „ébresztéshez” valószínűleg egy másik kiszolgálót használunk. No meg, 1 kiszolgáló esetén önmaga a DC is, amit meg tényleg nincs miért leállítani – s még lehetne sorolni a különböző érveket.

No de menjünk tovább, nézzük az Application naplót a kérdéses időpontokban – hiszen ő is arra hivatkozik, hogy egy alkalmazás állította le, reméljük olyan, amelyik készít naplózást. Máris két bejegyzés kerül elénk, egy hiba meg egy információs fokozatú (idő szerinti sorrendben):

APC UPS Service 61503:

Internal Communication Fault with your battery backup.

APC UPS Service 177:

PowerChute causing PC to hibernate.

Ez már egy nyom, amin el lehet indulni. Tehát valamiért megszakadt a kapcsolat a szünetmentessel, emiatt pedig az alkalmazás kiadta a hibernálási utasítást. Eleve rossz gondolatnak tartom, hogy egy kapcsolat-szakadás miatt ilyen döntést hozzon az alkalmazás, de sajnos az alkalmazás beállításainál nincs erre vonatkozó szabályozási lehetőség.

Rendben, feltártuk a hibát, nézzük, milyen lehetőségünk van a megszüntetésre. Mivel az alkalmazás verziója a legfrissebb, s nincs benne erre vonatkozó állítás, a szünetmentes USB-n keresztül csatlakozik a kiszolgálóhoz, sok esélyünk nincs, így a gyártóhoz fordultam.

A gyártóval történt levelezgetés után kiderült, hogy hol történt az elhibázott döntés:

„A PCBE csak SMART UPS termékekkel működik.

A PCPE csak BACK UPS termékekkel működik.

A Windows 2012  operációs rendszerrel nem fog működni csak a PCBE; ebben az esetben egy SMART UPS-re van szüksége.”

Tekintettel arra, hogy az UPS vásárlásakor egy XP volt „a szerver”, s a „kolléga” nem gondolkozott elég éretten (vagy anyagi megfontolásból), egy olyan terméket vásároltak, amelyik nem kiszolgáló-oldali célfelhasználásra van kitalálva (mondjuk jó pont, hogy egyáltalán gondolt szünetmentesre). Emiatt a szerverre is csak a PCPE telepítése során lehetett az eszközzel felvenni a kapcsolatot, ami „nagy vonalakban” jól működik – de „apróbb” hibák előfordulnak. Pl, hogy időnként hibernálja a szervert. Random időpontokban.

p.s. Nemrég kaptam a képet, hogy ha letiltásra kerül a hibernálás a kiszolgálón (milyen eretnek gondolat, brr…), akkor a program panaszkodik: