error címkéhez tartozó bejegyzések

Bitlocker TPM nélkül

A közhiedelemmel ellentétben igenis használható a Windows beépített Bitlockere a merevlemez tartalmának titkosítására akkor is, ha nincs a gépünkben TPM chip. Azokat a meghajtókat, amik az adatainkat tartalmazzák, simán hagyja is a Windows titkosítani, mindössze egy jelszót kér, és felajánlja a recovery key mentését fájlba, USB meghajtóra, sőt akár a felhőbe is. Ha viszont a C: meghajtónkat akarjuk bebitlockerezni, akkor találkozhatunk ezzel a hibaüzenettel:

This device can’t use a Trusted Platform Module. Your administrator must set the “Allow BitLocker without a compatible TPM” option in the “Require additional authentication at startup” policy for OS volumes.

bitlocker-1-tpm-error

Szerintem ez egy egészen jó hibaüzenet, mert megmondja, hogy mi a gond, és azt is, hogyan tudunk kimászni belőle. Ha még azt is megmondaná, hol keressük pontosan ezt a beállítást, egészen tökéletes lenne!

A “policy” szóra keresve ugyanis léptem nyomon a Local Security Policy-ba futhatunk bele, pedig nem az kell. A Group Policy Object Editorra van szükségünk még akkor is, ha workgroupban van az adott gép és nem tartományban. (A csoportházirendekről nekem mindig a címtár jut eszembe…)

Indítsunk tehát egy Microsoft Management Console-t (mmc), majd adjuk hozzá a Group Policy Object Editor snap-int (katt a teljes képért):

bitlocker-2-mmc-add-snapin

Ezen belül a Local Computer Policy –> Computer Configuration –> Administrative Templates –> Windows Components –> BitLocker Drive Encryption –> Operating System Drives ág alatt találhatjuk meg a hibaüzenetben megjelölt beállítást:

bitlocker-3-policy-path

A beállításra duplán kattintva előbb válasszuk ki az Enabled lehetőséget, majd alul pipáljuk be az Allow Bitlocker without a compatible TPM jelölőnégyzetet:

bitlocker-4-policy-setting

Miután mindent leokéztunk még frissítenünk kell a házirendet, amit a gépünk újraindítása nélkül legegyszerűbben parancssorból a gpupdate parancs kiadásával tehetünk meg:

bitlocker-5-gpupdate

Ezután már gond nélkül titkosíthatjuk az operációs rendszert tartalmazó meghajtónkat is.

 

Technorati-címkék: ,,

ISO fájl megnyitása nem sikerül

Windows 8 alatt már nem egyszer belefutottam az alábbi hibaüzenetbe, mikor egy ISO fájlt próbáltam a Windows Explorer segítségével mountolni:

“You don’t have permission to mount the file.”

 

no-permission-to-mount-the-file

Pánikra semmi ok, vaklárma az egész, valójában szépen megcsinálta, amit kértünk tőle, ott virít az új meghajtó a My Computerben.

 

Technorati Tags: ,,

Ott a fájl, de mégis 404

Próbálnék betölteni egy ASPX fájlt, de sehogy nem akar sikerülni. Pontosabban IIS Expressen a forráskódot futtatva megy kiválóan, de IIS-re publisholva 404 lesz belőle.

Látszólag minden rendben van, ott van a fájl a szerveren, csak épp nem töltődik le. Bekapcsolom a Failed Request Tracinget, hátha látszik valami. Látszik bizony: 388 napló bejegyzés egyetlen HTTP kéréshez. Még szerencse, hogy van Request Summary nézet, ami rögtön kiemeli az egyetlen warningot:

MODULE_SET_RESPONSE_ERROR_STATUS

ModuleName: ManagedPipelineHandler

Notification: EXECUTE_REQUEST_HANDLER

HttpStatus: 404

HttpReason: Not Found

HttpSubStatus: 0

ErrorCode: The operation completed successfully. (0x0)

Önmagában nem éppen nagy segítség, de legalább kiderült belőle, hogy melyik modul a bűnös. Kis öröm. Kikeresem a bejegyzést a Complete Request Trace-ből és megnézem, mi van előtte. AspNetParse és AspNetCompile bejegyzések. Talán valami gond van az ASPX fájllal? Nem valószínű, hiszen IIS Expressben megy, ráadásul NuGet package-ből jött.

Azért csak megnézem a forráskódot. Rögtön az első sor gyanús: a @Page direktívában CodeFile szerepel. Szokatlan. Átírom CodeBehindra. Fordítok, telepítek.

Megjavul.

Technorati-címkék: ,,

Visual Studio: Unable to check out the current file

Érdekes hibába futottam bele, miközben egy szolgáltatás referenciát próbáltam felvenni Visual Studioba. Az URL egy .svc fájlra mutatott, aminek a szerkezetét az Add Service Reference dialógusablak gond nélkül felismerte, ám az ablak bezárásakor a Studio a következő hibaüzenettel örvendeztetett meg:

Unable to check out the current file.  The file may be read-only or locked, or you may need to check the file out manually.

Bár az adott projekt történetesen valóban source control alatt volt, Git-ről lévén szó a “check out” kifejezés nem tűnt helyénvalónak. Az igazság az, hogy a fenti hibaüzenet teljesen rossz és semmi köze a verziókezelőhöz, és a megoldás az, hogy nem közvetlenül az Add Service Reference, hanem azon belül az Advanced gombra, majd az Add Web Reference gombra kattintva megjelenő dialógusablakot kell használni az adott szolgáltatás esetén.

 

Technorati-címkék: ,,

TFS adatbázis költöztetése másik szerverre

Előfordulhat, hogy a Team Foundation Serverünk adatbázisát át kell vinnünk másik gépre, például mert:

  • Frissítjük alatta a hardvert vagy a szoftvert (migration upgrade).
  • Szét szeretnénk osztani az adatokat több TFS szerver között (split).
  • Szeretnénk egy másolatot az éles adatokról teszteléshez.

A folyamat viszonylag egyszerű, de a sorrend fontos:

  1. Gondoskodjunk róla, hogy a célkörnyezetben egyező vagy frissebb verziószámú SQL Server legyen. Ez azért kell, mert az újabb SQL Serveren készült mentést a régebbiekre nem lehet visszaállítani.
  2. Gondoskodjunk róla, hogy a célkörnyezetben pontosan egyező verziószámú TFS legyen, beleértve nem csak a nagyobb javítócsomagokat, hanem minden hotfixet.
  3. A forrás szerveren:
    1. A TFS Admin Console-on állítsuk le a project collectiont (Stop Collection).
    2. A TFS Admin Console-on válasszuk le a leállított project collectiont (Detach Collection).
    3. Az SQL Server Management Studio segítségével készítsünk egy teljes mentést a project collection adatbázisáról.
  4. Vigyük át a mentést a cél szerverre.
  5. A cél szerveren:
    1. Az SQL Server Management Studio segítségével állítsuk vissza az adatbázis mentést egy új adatbázisba.
    2. A TFS Admin Console-on csatoljuk fel az adatbázist (Attach Collection).
    3. Szükség szerint módosítsuk a SharePoint és Report Server beállításokat.

Előfordulhat, hogy a cél szerveren nem sikerül felcsatolnunk az adatbázist, hanem az alábbi hibaüzenetet kapjuk:

TF254078: No attachable databases were found on the following instance of SQL Server: MyServer. Verify that both the name of the server and the name of the instance are correct and that the database was properly detached using the detach command in the Team Foundation Administration Console.

tfs-attach-db-not-found

A hibaüzenet egészen jó, ezeket kell ellenőrizni:

  • Valóban sikerül-e csatlakozni, méghozzá a TFS Service account nevében a megadott SQL Server példányhoz és azon belül az adatbázishoz.
  • Valóban azonos TFS verzió van-e a forrás és a cél környezetben.
  • Nem hagytuk-e ki a 3b. lépést, azaz az SQL mentés előtt rendesen leválasztottuk-e a TFS-ről az adatbázist.

A második és harmadik kritériumot a TFS úgy ellenőrzi, hogy először lekérdezi az SQL Serveren lévő adatbázisokat, majd mindegyiken lefuttatja az alábbi lekérdezést:

SELECT name, value 
FROM   sys.extended_properties 
WHERE  name LIKE 'TFS_%'

Azaz lekérdezi a “TFS_”-sel kezdődő egyedi tulajdonságait az adatbázisoknak. Ellenőrzésképpen ezt mi is megtehetjük a cél környezetben a Configuration adatbázison, és valami hasonlót kell kapnunk:

tfs-properties-configuration-db

Egy korrektül felcsatolt adatbázison:

tfs-properties-attached-db

És végül egy korrektül leválasztott adatbázison:

tfs-properties-detached-db

Ha nem találjuk a TFS_SNAPSHOT_STATE tulajdonságot Complete értékkel, akkor gyanakodjunk, hogy elfelejtettük a Detach Collection gombot megnyomni a TFS Admin Console-on.

 

Technorati-címkék: ,,

UriFormatException TFS teszt e-mail küldésekor

A Team Foundation Server Administration Console egy igen barátságos alkalmazás. Látszik, hogy a felület tervezésekor végiggondolták a tipikus üzemeltetői feladatokat, ezért lehet például könnyen megváltoztatni a service accountot vagy a szerver URL-jét, ráadásul szinte minden beállítás mellett ott van kéznél egy Test gomb, amivel gyorsan kipróbálhatjuk, hogy jó értéket adtunk-e meg.

Az egyik hasznos funkció, hogy a levelezési beállítások mellett található egy Send Test Email funkció:

tfs-email-settings

Ha rákattintunk, akkor a felugró ablakban meg kell adnunk a teszt levél címzettjének e-mail címét és egy szöveget, ami bekerül a levélbe:

tfs-test-email

Ha szerencsénk van, akkor simán el is megy a levél:

tfs-test-email-success

Azonban előfordulhat, hogy nem sikerül a küldés, hanem az alábbi hibaüzenetet kapjuk:

Unable to connect to the TFS server to test email settings. Url = ‘/_api/_common/TestMailSettings?sendTo=myuser%40example.com&message=Test+email’. Exception = System.UriFormatException: Invalid URI: The format of the URI could not be determined.
   at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind)
   at System.Net.WebRequest.Create(String requestUriString)
   at Microsoft.TeamFoundation.Admin.Console.Models.DlgSendTestMailViewModel.SendEmail()

tfs-test-email-error

Az ember ilyenkor átnézi az e-mail küldés beállításait, csakhogy a hibát jelen esetben nem ott kell keresni. Nyissuk meg a Change URLs ablakot, és ellenőrizzük, hogy a Server URL rovatban a Use localhost opció legyen kiválasztva:

tfs-change-urls

Az e-mail küldéses hiba ugyanis csak akkor jön elő, ha a második opciót választjuk, és localhost helyett a gép nevét adjuk meg a Use: rovatban. Akit érint, a Connecten szavazhat, hátha hamarosan kijavítják.

 

Technorati-címkék: ,

Amikor kell a régi Framework verzió az új mellé

Van egy alkalmazásunk, ami .NET Framework 4.0 Client Profile-t és SQL Server Compact Editiont használ, ClickOnce-szal települ, és ha szükséges, telepíti maga alá a Frameworköt is. Nincs benne semmi olyan, ami miatt ne futhatna régebbi Windowsokon, ami kell is, mert a felhasználóknál részben XP-k vannak. Az új verzió tesztelése közben szokás szerint felhúztam egy friss XP-s virtuális gépet, amire az alkalmazás új verziója sikeresen települt is, azonban az első adatbázis műveletnél az alábbi hibával elszállt:

System.DllNotFoundException: Unable to load DLL ‘sqlceme35.dll’: The specified module could not be found. (Exception from HRESULT: 0x8007007E)

A hivatkozott fájl természetesen ott volt a diszken, ahol a korábbi verziókban is, sőt a program új verziójába nem is kerültek olyan változások, amik ezt a hibát indokolták volna, ezért jogosan merült fel a kérdés, hogy mi változott?

A hiba nem jött elő sem Windows 8.1-en, sem Windows 7-en, sőt még azokon a régebben használt XP-s gépeken sem, amiken fent volt az alkalmazás korábbi verziója, és most csak frissítettük. És bár a korábbi verzió vígan futott XP-n, az új virtuális gépben ugyanolyan hibát produkált, mint az új verzió, így adódott a következtetés, hogy a virtuális gépben volt az eltérés.

Először a modern.ie oldalról letöltött virtuális gépet használtam, és arra gyanakodtam, hogy annak van valami specifikuma. Azután telepítettem egy saját virtuális gépet úgy, hogy az alap XP+SP3 telepítőre hosszú órák alatt keservesen felkínlódtam az összes Windows Update frissítést. A jelenség ugyanaz.

Végül ILSpy-jal belenéztem a programmal települő System.Data.SqlServerCe szerelvénybe, és mivel az még a .NET Framework 2.0 verziójára hivatkozott, próbaként feltelepítettem a régi Framework verziót. Csodák csodája a probléma megoldódott.

Az eset érdekességei:

  • A Windows Update nem telepítette a .NET Framework 2.0-át, csak az újabb verziókat. Ez régebben nem így volt.
  • A 4.0 Client Profile nem volt elég, mellé fel kellett telepíteni a 2.0 verziót.
  • Érthető, hogy Windows 7-en nem jött elő a hiba, hiszen ott az operációs rendszer része a .NET 2.0, de vajon miért ment simán 8.1-en, ahol alapból nincs feltéve a .NET 2.0?

 

Technorati-címkék: