Amikor a felhasználói profil szolgáltatás nem tud bejelentkezni

Egy Windows 7-en futottam bele az alábbi hibába, amikor a helyes jelszót megadva próbáltam bejelentkezni:

A(z) Felhasználói profil szolgáltatás nem tudott bejelentkezni. A felhasználói profilt nem sikerült betölteni.

Szerencsére létezik a problémára egy 947215 számú tudásbázis cikk, amiből kiderül, hogy ez a jelenség “alkalmanként előfordulhat”. Hurrá!

A cikk szerint először is kellene egy másik felhasználó, akinek a fiókjával sikerül a bejelentkezés. Pechemre másik felhasználó nem volt a gépen, de szerencsére csökkentett módban nem jött elő a hiba, és az egy szem felhasználónak voltak rendszergazdai jogai, így végül sikerült egy másik felhasználót létrehozni. Így használhatóvá vált a gép, de még hiányoztak a profilhoz tartozó fájlok.

A cikk szerint a következő tiszta lépés a profil másolása a régi fiókról az újra, itt azonban a helyhiány problémájába futottam bele. Így maradtam a registry matatásnál. A második felhasználó nevében előkaptam a regedit-et és kikerestem ezt az ágat:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

Itt érdekes módon két nagyon hasonló nevű mappa szerepelt:

• S-1-5-21-…-1001
• S-1-5-21-…-1001.bak

A .bak végződésűben sok beállítás volt és mind helyesnek tűnt, a .bak nélküliben viszont alig volt pár érték és például a ProfileImagePath hiányzott.

Átnevezéssel felcseréltem a két mappát, újraindítottam a gépet és tada, minden működött szépen!

 

Technorati-címkék: Windows

Hibernálás engedélyezése Windows 8-on

A frissen telepített Windows 8.1 RTM gyönyörűen felismert minden eszközt a gépemben, semmilyen driver hiba nem volt, mégsem jelent meg a Hibernate opció a Shut down or sign out menüben. Első körben engedélyeztem a hibernálást a powercfg /h on paranccsal, ami hiba nélkül le is futott, a menüpont mégsem jelent meg.

Úgy tűnik, azt külön engedélyezni kell, méghozzá így:

A Power Options ablak bal oldalán található a Choose what the power buttons do menüpont:

A megjelenő Define power buttons and turn on password protection ablak alján lehet engedélyezni a hibernáló gomb megjelenítését rendszergazdai jogosultságokkal:

Ezután már lehet több helyről is hibernálni:

 

Technorati-címkék: Windows 8,power

ASP.NET 4.0 űrlap alapú hitelesítés IE11 alatt

Korábban már említettem, hogy a böngészők detektálásán alapuló megoldások gondot okozhatnak, amikor megjelenik egy új böngésző vagy egy új böngésző verzió. Sajnos mivel az ASP.NET korábbi verziói is tartalmaznak böngésző detektálós részeket, az Internet Explorer 11 megjelenése ott is gondot okozhat.

Véletlen egybeesés, hogy az említett cikk után egy nappal Eric Lawrence is írt egy cikket az IE11-ről és a User-Agent sniffingről. Néhány érdekesség belőle:

• Az IE csapat szándékosan úgy választotta meg a UA stringet, hogy a weboldalak inkább WebKites böngészőnek ismerjék fel, mint régebbi IE verziónak.
• A nyár folyamán az ASP.NET csapat kiadott frissítéseket a probléma megoldására, például .NET 4.0-hoz a KB2836939-et. A többi frissítés listája megtalálható a cikkben.

Mi egy olyan problémába futottunk bele korábban, hogy az IE11 lelkesen felküldte az ASP.NET forms authentication cookie-t a szervernek, de a szerver fittyet hányt rá. A web.config fájlban lévő forms elemnél korábban nem szerepelt a cookieless attribútum, mert az alapértelmezett UseDeviceProfile eddig tökéletesen működött, most viszont explicit módon be kellett állítanunk a UseCookies értéket, hogy az oldal IE11-gyel is működjön rendesen.

Itt egy régebbi szerverről volt szó, amin ASP.NET 4.0 futott a fenti frissítés nélkül, 4.5-ön ezt nem tapasztaltuk.

Megjegyzem a cookieless="UseCookies" biztonság szempontból is a javasolt beállítás.

 

Technorati-címkék: IE,Windows 8,ASP.NET,security

IE11 User-Agent string

A Windows 8.1-ben megjelenő Internet Explorer 11-hez tartozó User-Agent string (ez az, amit a HTTP kérésben a böngésző felküld a szervernek) a következő:

Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko

Akkor lesz nyilvánvaló, hogy mi ebben az érdekes, ha összehasonlítjuk a korábbiakkal, például az IE10 és az IE9 azonosítójával:

Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Trident/6.0)
Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)

A formátum tehát teljesen megváltozott, sőt az MSIE jelölés teljesen eltűnt! Ez akkor okozhat gondot, ha valamilyen kliens vagy szerver oldali kódunkba böngészőfüggő viselkedést írtunk, ugyanis a régebbi kódunk nem biztos, hogy jól fogja felismerni az új böngészőt.

Az ASP.NET platformban is vannak olyan részek, amik tekintettel vannak a kliens böngészőjére, és sajnos korábban már volt rá példa, hogy egyes funkciók nem jól működtek az újabb böngészőkkel.

Szerencsére az ASP.NET böngésző detektáló része a .browser fájlok segítségével rugalmasan alakítható, amit az is jól mutat, hogy Windows 8.1-en a C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\Browsers mappában található ie.browser fájl már az új User-Agent stringnek megfelelő részt is tartalmaz:

<browser id="InternetExplorer" parentID="Mozilla">
   <identification>
     <userAgent match="Trident/(?'layoutVersion'[7-9]|0*[1-9]\d+)(\.\d+)?;(.*;)?\s*rv:(?'version'(?'major'\d+)(\.(?'minor'\d+)))" />
     <userAgent nonMatch="IEMobile" />
     <userAgent nonMatch="MSIE " />
   </identification>
   <capabilities>
     <capability name="browser"              value="InternetExplorer" />
     <capability name="version"              value="${version}" />
     <capability name="majorversion"         value="${major}" />
     <capability name="minorversion"         value="${minor}" />
     <capability name="layoutEngine"         value="Trident" />
     <capability name="layoutEngineVersion"  value="${layoutVersion}" />
     <capability name="type"                 value="InternetExplorer${major}" />
   </capabilities> 
</browser>

A tapasztalatunk az, hogy érdemes tesztelni az új böngészővel a régi webalkalmazásokat, még akkor is, ha a saját kódunkba nem írtunk böngészőfüggő részeket, mert a platform is tartalmaz ilyeneket. Különösen akkor érdemes odafigyelni, ha a szerver oldalon még ASP.NET 4.0 van, tehát nem a legfrissebb 4.5 (amit az in-place upgrade miatt nem mindenhol mernek telepíteni).

Egy következő cikkben írok majd néhány konkrét ASP.NET-es problémáról, amibe belefutottunk IE11-gyel.

 

Technorati-címkék: ASP.NET,browser,IE

Amikor az Outlook 2013-ból eltűnnek a mappák

Sajnos az Office 2013 szeptemberi frissítésébe kis hiba csúszott, amit úgy vesz észre az ember, hogy Outlook 2013-ban üres a folder pane:

Nem kell megijedni, a mappák megmaradnak, az üres helyet lehet minimalizálni, sőt a folder pane minimalizált működése továbbra is megvan. Tehát az Outlook használható marad, csak éppen használhatatlanul kényelmetlen.

A Microsoft elismerte a hibát és gőzerővel dolgoznak a javítás javításán: Outlook 2013 Folder Pane Disappears After Installing September 2013 Public Update

Addig is a megoldás a KB2817630 frissítés eltávolítása a Programs and Features ablakban. Vigyázat, trükkös! Kétszer jelenik meg a listában és mindkettőt el kell távolítani:

A másik trükk, hogy eltávolítás után a frissítés lelkesen visszamászik a következő frissítésnél, tehát a WSUS szervereken érdemes Decline-ra tenni ezt az update-et.

 

Technorati-címkék: WSUS,update,Office

Egyetlen URL a Dashboardokhoz

Nem tudom, hogy más hogy van ezzel, de engem zavar, hogy a Windows 8 és a Windows Phone alkalmazások fejlesztésénél 2 URL-t kell fejben tartanom:

• Windows Phone esetén: http://developer.windowsphone.com
• Windows 8 esetén: http://msdn.microsoft.com/en-US/windows/apps

Persze az MSDN nyitóoldalról mindent el kellene tudnom érni, de nekem ez még a redesign után sem sikerül. (A hiba valószínűleg nem bennem van, mert ez a probléma újra és újra előjön levelezőlistákon.)

Ezért az utóbbi időben rászoktam a http://www.windowsstore.com/ címre.

Ha a Windows 8 Dashboard kell, akkor a jobb felső sarokban lévő Visit the Dev Center linkre kattintva bejövő oldalon a felső menüben már van Dashboard link.

Ha Windows Phone kell, akkor a fejlécben átkattintok a Windows Phone ikonra, majd azon az oldalon jobb felül Visit the DevCenter, és végül Dashboard.

Érdemes megnézni a linkek mögött szereplő URL-eket és domain neveket. Nagyon kreatívak, de a logikát nem látom bennük.

Ez még így is 3 kattintás, de legalább csak 1 címet kell fejben tartanom. Tud valaki egyszerűbb megoldást?

 

Technorati-címkék: Windows Phone,Windows Store,Windows 8,MSDN