A tesztelés fontossága

december 2, 2020 1 hozzászólás

Adott helyen megkértek, hogy néhány fürtöt nézzünk át közösen, valamint azokon minimális módosításokat szeretnének. Ahogy haladtunk előre a munkával, dőltek ki a csontvázak a szekrényből, de a legnagyobb az utolsó fürt esetén jött elő.

Ez egy SQL-clusternek nevezett szolgáltatás volt. Az addigi tapasztalatok alapján, no meg a normális emberi gondolkodás szerint is, az első lépés az volt, hogy jelen állapotában teszteljük a működését. Ez azt jelentette, hogy a szolgáltatást a fürt egyik tagjáról átbillentsük a másikra. Nos, “természetesen” elhasalt. Ideiglenesen visszaállítottuk, s elkezdtük a hibakeresést, ami egy számomra teljesen szokatlan helyzetet mutatott ki: nem egy beállítás, nem egy pipa okozta a gondot, hanem az SQL-szerver telepítés hiánya. Előbbit még mondjuk így-úgy meg lehet magyarázni, hogy időközben állítódott el (persze, magától 😛 ), de egy egész SQL-telepítést? Ugye tanfolyamokon szoktunk viccelni, amikor idő szükséges, hogy semmi gond, addig telepítsünk egy SQL-t. Tudjuk jól, hogy nem 2 másodperc. S tudjuk jól, hogy legtöbb ember grafikus varázslóval megy rajta végig, akár telepítés, akár eltávolításról van szó. Szóval egy ilyen, rengeteg paramétert igénylő eltávolítást szerintem nem lehet “véletlenül” végrehajtani. De akkor mi történt?

Nos, valószínűleg emberi mulasztás. Lehet, hogy rohamtempóban kellett felhúzni a fürtöt, s nem volt idő a másik tagra telepíteni az SQL-t. Vagy valamilyen hiba következett be a telepítés során, amire elfelejtettek visszatérni. Vagy tudatlanság miatt: nem tudták, hogy mindkét kiszolgáló kell rendelkezzen telepített SQL-el. Vagy… lehetne sorolni a különböző forgatókönyveket.

A legnagyobb hiba viszont a végén van: átadás előtt tesztelni kellett volna. Hogy valóban átbillen-e, hogy valóban jól működik. S ha igen, csak akkor átadni használatra, ha nem, akkor jelezni, hogy pillanatnyilag működőképes, de NEM fürt. Ezáltal az érintettek is tudták volna, hogy mi is van a motorháztető alatt. Mi lett volna, ha mindez “élesben” derül ki, amikor az addig használt kiszolgáló ilyen-olyan okokból kifolyólag kidől?

Kategóriák:General, Windows Server Címkék: ,

Azok az Exchange 2003-as maradványok…

november 9, 2020 Hozzászólás

Nemrég egy elég ritkán felmerülő esetben segítettem, így – mivel Zolival ellentétben még nem szálltam ki az Exchange-ek világából – gondoltam megírom.

Az egész azzal kezdődött, hogy adott cégnél hibrid megoldást akartak bevezetni; a kolléga elkezdte az összes szükséges dolgot előkészíteni, majd megvalósítani. Adott ponton a varázsló módosítani akarja az alapértelmezett email-házirendet (Default Policy), ám adott esetben egy hibaüzenetet dobott:

HCW8097 – You must upgrade your Email Address Policy before running the Hybrid Configuration Wizard

Rákeresve a neten, mindenhol arra utalnak, hogy régebbi (értsd Exchange 2003-as) maradványok lehetnek a rendszerben, s ezt milyen módon lehet kiküszöbölni. Igen ám, de a javasolt módszerek, pl. ez:

Set-EmailAddressPolicy “Default Policy” -IncludedRecipients AllRecipients

vagy ez:

Get-EmailAddessPolicy | Update-EmailAddressPolicy

egyike sem vezetett eredményre.

A nyomozás során első körben mindenképp rákérdeztem, hogy valóban ez egy “görgetett” rendszer, s a pozitív válasz miatt próbáltam mindenféle módon kideríteni, hogy miért gondolja az Exchange, hogy a jelzett házirend régi típusú. Ebben az alábbi parancs segíthet:

Get-EmailAddressPolicy | Fl Name,RecipientFilterType,ExchangeVersion,HasMailboxManagerSetting

Ennek kimenetele általában kétféle verzió szokott lenni:

RecipientFilterType: Legacy

ExchangeVersion: 0.0 (6.5.6500.0)

HasMailboxManagerSetting: True

vagy

RecipientFilterType: Precanned

ExchangeVersion: 0.1 (8.0.535.0)

HasMailboxManagerSetting: False

Jelen esetben a második állapot jelentkezett, így egyértelmű volt, hogy (mint utólag kiderült, még ha részlegesen is, de) megtörtént az átállás. De akkor hol a hiba?

Egy nyomot kaptunk a Set-EmailAddressPolicy futtatása során kapott hibaüzenet formájában:

The recipient policy “Default policy” with mailbox manager settings cannot be managed by the current version of Exchange Management Console. Please use a management console with the same version as the object.

A rejtett kulcsszó három szócska: “with manager settings“. Azt jelenti, hogy a házirendhez még hozzá van rendelve valami, ami már nem kellene ott legyen. Igen ám, de már régóta nincs Exchange 2003-as konzoljuk, amivel GUI-alapon megszüntessük ezt a “manager settings“-et. Sebaj, mivel az Exchange (szinte) mindent AD-ban tárol, szüntessük meg ott, ADSIEdit segítségével, a Configuration partícióban:

“CN=Recipient Policies,CN=Org Name,CN=Microsoft Exchange,CN=Services,CN=Configuration”

Egyrészt – ha ott van, akkor – vegyük ki a True állapotot az alábbi attribútumból: MsExchMailboxManagerFolderSettings

A második, sokkal fontosabb viszont a msExchPolicyOptionList attribútum, ahol az alábbi két érték szokott lenni:

FC 1C 49 26 50 9E 57 48 86 1B 0C B8 DF 22 B5 D7 = Address List policy

EC 13 68 3B 89 CE BA 42 94 42 D8 7D 4A A3 0D BC = MailBox Manager Policy

Ezek közül a gond a második, ezt kell eltávolítani (jó esetben az első eleve ott van), majd megvárni, hogy érvényesüljön. Ha minden más beállítás stimmel, mint az adott helyen, a fentiek után már sikeresen lefut a varázsló.

Saját CA által kiállított tanúsítványok vs böngészők

október 7, 2020 Hozzászólás

Nem új keletű a történet háttere, de gondolom az új Edge bevezetésével mind több helyen elő fog jönni, ezért úgy döntöttem, elébe megyek a dolgoknak.

Adott cégnél felmerült, hogy az eddigi http alapú intranet kommunikációt áthelyezik https-re. Ennek érdekében első körben történt egy CA-bevezetés, majd a kiszolgálóra igényeltek egy web-kiszolgálói tanúsítványt.

A tesztelés során kiderült, hogy azok, akik IE vagy “régi” Edge-ről töltik be az oldalt, nem tapasztalnak gondokat, viszont akik Chrome vagy Chromium alapú Edge-ből, azoknak

ERR_CERT_COMMON_NAME_INVALID

hibaüzenettel, a Firefox-ból vonulóknak pedig egy

SEC_ERROR_UNKNOWN_ISSUER

üzenettel kedveskedik a rendszer.

Itt akkor felmerült a kérdés: most akkor mi van? Jó a tanúsítvány vagy nem? Illetve miért függ egy tanúsítvány megítélése a böngészőtől?

Nos, Firefox esetén a böngészőnek saját tanúsítvány-tára (is) van, de esetében mondhatni könnyű dolgunk van: egy házirend segítségével megadjuk, hogy a böngésző az oprendszertől kérje el a megbízható tanúsítványok listáját. S tudjuk, hogy a CA automatikusan lekerült a gépekhez, tehát ez nem lehet gond (erre amúgy másodlagos bizonyíték az is, hogy az MS régebbi böngészői sem reklamálnak). Itt “csak” egy dolog nem teljesen világos számomra: miért szükséges, hogy egyes programok (pl. Adobe, Java, stb) saját tanúsítványtárat használjanak? Értem én, hogy így akár szolgáltatásonként külön tanúsítványt lehet használni – de személy szerint ezt már túlzásnak érzem…

A Chrome / Chromium alapú Edge esetében a megértéshez szükséges a Google böngészőjének működését figyelembe venni. Kb. 3 éve ugyanis a Chrome nem fogadja el a belső CA-k által kiállított tanúsítványokat, csak akkor, ha azok rendelkeznek érvényes SAN-mezővel. Ezzel a gondolattal lehet vitatkozni, ugyanis elvileg az RFC előírja, hogy másodlagos opcióként a CN-t is ellenőrizni kell – de ez figyelmen kívül van hagyva. Egy ideig egy registry-kulccsal lehetett egy kerülő-megoldást alkalmazni, viszont ezt a lehetőséget is már rég megszüntették. Jelen esetben megoldásként az a döntés született, hogy rendben, akkor létrehoznak egy új, célnak megfelelő tanúsítvány-sablont, majd azzal igényelnek tanúsítványt. Ennek szétszedése (Cert, Key, CA) már gond nélkül lezajlott, majd az élesítés után már valóban nem reklamált a böngésző. De hogy mit tesznek azok a cégek, ahol tömegesen használnak web-kiszolgálókat, saját CA-val, s tömegesen akarják lecserélni a tanúsítványokat az újabb sablonból eredőnek – hát, lehet, hogy nem mindenki lesz boldog.

BIOS vs Hyper-V

szeptember 28, 2020 Hozzászólás

Adott helyen egy tavaly vásárolt szerver mellé idén vettek egy másodikat, fürtözés céljából. Ebből a gondolatmenetből kifolyólag ugyanolyan gyártó, ugyanolyan típus lett véve, majd az újra is telepítették a Win2019-et.

Előkészítés után (tartományba léptetés, iSCSI beállítások, stb) után sikeresen létrehozták a fürtöt, majd következett a tesztelés: egy adott Hyper-V virtuális gép mozgatása. S itt jött az érdekes hibaüzenet:

System 21502:

Live migration of ‘Virtual Machine VM1’ failed.

Virtual machine migration operation for ‘VM1’ failed at migration destination ‘H1’.

The virtual machine ‘VM1’ is using processor-specific features not supported on physical computer ‘H1’. To allow for migration of this virtual machine to physical computers with different processors, modify the virtual machine settings to limit the processor features used by the virtual machine.

Ekkor nyomták meg a piros gombot.

A hibakeresés során természetesen ellenőriztük a gépek, azon belül kiemelten a procik adatait, amelyek megegyeztek. Időközben viszont jött az első tippjük és egyben kérésük: eszükbe jutott, hogy tavaly még Legacy (BIOS) módban történt a Windows telepítése, idén pedig már UEFI módban. Kérték, hogy mielőbb továbbmegyünk, lehetőség szerint tegyem át a régit is UEFI-módba. Szerencsére korszerű oprendszerrel dolgozva, nincs sok tennivalónk: egy teljes körű mentés után – kis üzemszünettel számolva – át tudjuk állítani.

Emelt szinten futtassuk az MBR2GPT parancsot, előbb csak validálás üzemmódban, megbizonyosodva, hogy valóban működhet a konverzió. Ha nincs gond, akkor futtassuk újra, most már élesben, s hamarosan jelzi, hogy a gép készen áll az újraindításra. Az oprendszer elindulásához ne felejtsük BIOS-ban átállítani a Boot-folyamatot UEFI módba, s jó esetben ki is pipálhatjuk ezt a kérdést.

Adott helyen a Windows sikeres indítása után volt még egy apró gond, ugyanis a VM-ek nem voltak hajlandóak elindulni:

“Virtual Machine could not be started because the hypervisor is not running”

Ellenőrizve a BCD-t, megtaláljuk a hibát, amit az alábbi sorral orvosoltunk:

bcdedit /set hypervisorlaunchtype Auto

Ezt is rendbetéve, jöhetett a valódi probléma körbejárása. Természetesen megoldhattuk volna úgy, hogy a VM-eknél egyesével bekapcsoljuk a processzornál a kompatibilitást, de akik ismernek, tudják, hogy szeretem körbejárni alaposan a problémát (B-tervnek természetesen ott van ez is).

Néhány célzott keresés vezetett erre a cikkre. Nos, ellenőrizve, igaz, hogy már a tavalyi gépen található BIOS sem volt régi, bőven a Spectre utáni, de azóta kijött még két verzió, amelyek az új gépre már felkerültek. Szerencsére a gyártó honlapján volt leírás a BIOS-verziók újdonságairól, így amikor azt láttam, hogy “Updated the Processor Microcode“, reménysugár csillant meg az alagút végén. A letöltés, majd telepítés után valóban megnyugodhattunk, ugyanis a problémás hibaüzenet már nem jelentkezett, a mozgatás is sikerült.

A kollégáknak is tanulság volt, hogy a driverek, javítófoltok stb mellett érdemes figyelni a BIOS-verziókra is – főleg egy fürt tagjai esetén, hiszen eltérő verziók esetén ilyen gond is felmerülhet 🙂

Kategóriák:Virtual Server/Hyper-V Címkék: , ,

Management konzol és tanúsítvány

augusztus 7, 2020 3 hozzászólás

Egy adott cégnél feltették adott (egyik általam is kedvelt) végpontvédelmi alkalmazás központi kezelőfelületét. A telepítés rendben lezajlott, viszont a következő lépés során hiába keresték a program nyilvántartásában a kliens-gépeket, a lista üres volt.

A hibafeltárás során először is megnéztük, hogy lefutott-e az AD-ból történő import. Mivel a feladat hibát jelzett, így egyértelmű lett, hogy “csak” ennyi a baj. No de miért futott hibára?

Nos, a nemrég, júniusban kiadott legújabb verzió tartalmaz egy elég fontos változást ezen a téren – így vélhetően lesznek még néhányan, akik konzol-frissítés után szintén belefuthatnak a sikertelen műveletbe. Kissé kettős érzéssel vagyok, ugyanis érzem, hogy az elképzelés, alapötlet nem rossz, de sajnos a kivitelezés nem sikerült a legjobban.

Hogy konkrétan az okot nézzük: bevezették, hogy az AD-import LDAPS segítségével történjen. Ez szuper, hiszen ez a biztonságot erősíti, nem? De igen, de mi van azoknál a cégeknél, ahol még nincs PKI rendszer bevezetve, a DC-knek nincs megfelelő tanúsítványa? Nos, itt csúszott el a történet. Idézem a támogatói oldal erre vonatkozó cikkét: a DC-n Server Manager segítségével telepítsük az AD CS szerepkört, azon belül a CA-t. Ezután a Helyi számítógép tanúsítványai ablakban jobb klikk segítségével kérjünk DC-tanúsítványt. S kész.

Aki nem foglalkozott soha tanúsítványokkal, talán az is érzi, hogy ez elég foghíjas. Kezdve attól, hogy egy tanúsítvány-kiszolgálót nem vezetünk “csak úgy” be egy tartományba, arról nem beszélve, hogy a binárisok telepítése (Server Manager, ugye) után még van a CA élesítése. Erről a cikk mélyen hallgat, tehát aki a varázslót lefuttatja, az törheti a fejét, hogy Enterprise (default) vagy Standard, Root (default) vagy Subordonate, új privát kulcs vagy nem (ennek minden finomságával) szükséges – vagy csak rányom a Next-Next-Finish gombra, de attól még nem tudja, hogy mit csinál.

Amennyiben sikerül a CA-t telepíteni, jöhet a következő lépés, ami valóban nem annyira bonyolult: a DC-nek tanúsítványt kérni. Még itt is elbizonytalanodhat a szomszéd Pistikéje, ugyanis két tanúsítvány-sablonban is szerepel a “Domain Controller” szópáros

Csak, hogy teljes legyen a lista, egy másik apróság is kibukott (ez már csak helyi “specialitás”): az előbbiek abszolválása után még mindig nem tudott a kiszolgáló LDAPS kapcsolatot létesíteni a DC-vel. Ennek okának kiderítése kicsit kacifántosabb volt, a semmitmondó hibaüzenet (ami ráadásul ugyanaz volt, mint a CA telepítése előtt) nem segített semmit. Bár tudjuk, hogy Ent CA esetén a kiszolgáló tanúsítványa automatikusan bekerül a megfelelő helyre, így nem GPO-val kell kiszórni a tartományi gépekre, adott gépen ez nem valósult meg, így kerülő-megoldásként kézzel került be a megfelelő konténerbe – ezzel végre kerekké (és sikeressé) téve a történetet.

A teljesség kedvéért meg kell említeni, hogy egy másik opció segítségével maradhatunk LDAP csatlakozásnál is, sőt, megfelelő sablon segítségével a szükséges Active Directory attribútumokat is ki tudjuk töltetni – de szerintem első körben elég lett volna egy pipa-beállítás, hogy aki szeretné, tudjon használni LDAPS-ot, majd később szigorítani, s alapértelmezetté tenni.

Kategóriák:General, PKI Címkék: ,

Hyper-V apróságok

június 18, 2020 Hozzászólás

Kissé el vagyok havazva, így most csak két apróságot jegyzek fel:

  1. Management konzol “History” törlés

Néha zavaró tud lenni, ha egy megszűnt/elgépelt Hyper-V gazdagép nevét látjuk a varázslókban (gazdagép hozzáadása, replika létrehozása, stb), de szerencsére könnyen orvosolható.

Természetesen bezárt Hyper-V Manager konzol mellett nyissuk meg az %AppData%\Microsoft\Windows\Hyper-V\Client\1.0\ könyvtárat, majd itt a VMBrowser.Config állományt nevezzük át/töröljük.

  1. VM mozgatás

Amennyiben egy másik gépre mozgatjuk a VM-et, szétválasztva szokás szerint a konfigurációs állományokat a virtuális lemezektől, ugyanakkor a gépre bízva az útvonalválasztást (Move virtual machine / Move virtual machine’s data by selecting where to move the items / Move the virtual machine’s data automatically), egy “apróságra” érdemes figyelni.

Hiába van bármi beállítva a cél Hyper-V konfigjában, a varázsló ugyanolyan betűjelű meghajtóra akarja tenni a virtuális lemezeket, mint a forrás oldalon – tehát ha nincs/nem elérhető az a meghajtó, hibát fog dobni. Megoldása itt sem bonyolult, a virtuális lemezek mozgatása oldalon más opciót választunk. Természetesen a Hyper-V-VMMS eseménynapló itt is segít, ha elakadnánk a hiba felderítésében…

Nyilvános mappák maradvány objektumai

május 12, 2020 Hozzászólás

Ott fejeztük be a történetet, hogy mehetett a tömeges migráció. Miután azzal is megvoltak, jött volna a Nyilvános mappák valódi migrációja (hiszen az első részben csak átproxy-zták a kéréseket a régi szerverekre).

Több leírás is van erre, hogy miként kell (pl. Paul írása), ettől függetlenül a migráció során találkozhatunk gubanccal.

Jelen esetben a migrációs feladat hibára futott:

MigrationTransientException: Couldn‎’t find a request that matches the information provided. Reason: No such request exists in the specified index. –> Couldn‎’t find a request that matches the information provided. Reason: No such request exists in the specified index.

Ennek alapján van még olyan nyilvános mappa, ami valamiért nem tetszik neki. Listázzuk ki:

Get-MailPublicfolder -ResultSize Unlimited

S igen, valóban jöttek elő “sárga” sorok, amelyek jelezték, hogy rengeteg rossz alias van. Kiderült, hogy ezek anno létező nyilvános mappák voltak, de az eltávolításuk valamilyen fura módon lehetett, ugyanis egy-egy objektumuk ott maradt a “Microsoft Exchange System Objects” OU-ban. Miután meggyőződtek róla, hogy valóban ezek csak maradványok, s törölték őket, már sikeresen lefutott a migrációs parancs.

Autodiscover és O365

április 20, 2020 2 hozzászólás

A következő probléma már más jellegű volt. Ugyanis átmigráltak néhány postafiókot, amiből egynél az Outlook folyamatosan feldobta a jelszókérő ablakot. Új Outlook-profil, új Windows-profil, másik gép nem segített – ugyanakkor OWA-n, telefonon nem volt semmilyen fennforgás.

A hibakeresés során már az furcsa volt, hogy az Outlook-profil beállításakor ismét jelszót kért; annál nagyobbra kerekedett a szemem, amikor láttam, hogy O365-re mutató autodiscover.xml hozzáféréséhez kéri a jelszót. Amikor ők nem is használnak ilyent. Pontosabban: nem volt információm róla, ezt elfelejtették közölni; valaki beállított egy O365 fiókot, de nem mérte fel rendesen a hatásait. Ráadásul belsőleg be volt ugyan állítva egy SRV rekord (a benti Exchange-kre), de publikusan nem volt ilyen. Szegény Outlook meg nem tudta, hogy mi legyen: többszöri próbálkozásra létrejött a profil, a program indításakor be is töltődött, letöltötte a leveleket, elküldte a kimenőket – de egy idő után, amikor ismét kinézett volna a kiszolgálóra, ismét kérte a jelszót (újra O365-re próbált csatlakozni), illetve onnantól nem küldött/fogadott, egy következő program-indításig.

A megoldásjavaslat egyszerű volt: vagy tegyék rendbe az O365-öt, vagy (ideiglenesen) kapcsolják ki a lekérdezését ezen cikk alapján, hozzák létre az

[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover]

“ExcludeExplicitO365Endpoint”=dword:00000001

registry-értéket. Innentől már tényleg mehetett a tömeges migrálás 🙂

Kategóriák:Exchange Címkék: , ,

Nyilvános mappák együttélés Exchange 2010 – 2016

március 19, 2020 5 hozzászólás

Adott helyen most érkezett el az idő, hogy migráljanak Exchange 2010-ről 2016-ra. A migráció előkészítése során eljött a Nyilvános mappák elérhetőségének problémája is, amit ebben (s szükség esetén ebben) a cikkben leírtak alapján érdemes végigvinni.

A piros gomb természetesen itt sem maradt el… Az első gond, ami felmerült, az volt, hogy a meglévő DAG kiszolgálókon csak egyikre hozták létre a PFProxy fiókot – miközben érdemes mindkét kiszolgálóra ezt megtenni. Egy másik gond egy beállítás volt: mivel új adatbázisok kerültek a szerverekre, amelyek csak a jelzett fiókokat tartalmazták, még egy dolgot javasolt beállítani: az RPCClientAccessServer értékét. Ez azért szükséges, mert ezek a fiókok vagy csak Exch1-en, vagy csak Exch2-n léteznek, ám a kliensek által használt hozzáférési pont egyszerre csak egyikre mutat – így előfordulhat, hogy pont a másik kiszolgálóra visz minket, mint amelyik PFProxy-t akarjuk elérni (pontosabban amelyik PFProxy nyilvános-mappa adatbázisát).

Az már csak “apróság” volt, hogy amivel akarták tesztelni (a fentiek javítása után) egy Outlook 2019 volt. Ez a hivatalos mátrix szerint nem jó az Exchange 2010-hez. Látszólag nincs vele baj, de miután végre eljutottak ahhoz a ponthoz, hogy megnyíljanak a Nyilvános mappák, az adott teszt-fiók teljes jogosultsága esetén is csak és kizárólag törlést engedett az adott nyilvános mappán (se új elem, se új almappa, gyakorlatilag semmi tevékenységre nem volt alkalmas). Amennyiben kérésemre ugyanezt egy 2016-os verzióval végezték, máris nyugodtan dőltek hátra: következett (volna) a postafiókok migrációja – de ez már egy másik problémát hozott elő 🙂

Mentés betűjel nélküli kötetre

január 22, 2020 4 hozzászólás

Adott helyen abban kérték a segítségem, hogy szeretnének mentést beállítani úgy, hogy a célhoz nem szeretnének betűjelet csatolni. A Windows-ba épített Wsbackup-ot akarták használni, ez is tud így menteni, viszont természetesen a kötet útvonalát valahogy meg kell adni.

Nos, itt csavarodott el a történet. Ugyanis a szükséges azonosító kiolvasására két eszközt (diskpart, wbadmin) is igénybe vettek, de sajnos nem voltak teljesen világosak a fogalmakban, így a kiolvasott adatok használatakor a következő hibaüzenetet kapták:

ERROR – The specified backup location could not be found or is not a supported backup storage location.

A feltárás során kiderült, hogy a mentési parancs teljes mértékben jól volt összeállítva, “csupán” a GUID volt hibás.

De akkor kezdjük egy rövid áttekintéssel (s itt most nem megyünk bele a RAID-tömbökbe, NAS-okba, SAN-okba, hanem egy “sima” lemezt nézzünk). Egy lemezen több kötet (állományrendszerrel rendelkező lemez-rész) lehet; míg a lemezeknél az azonosító (ID) a “DiskSignature” (MBR esetén “ABCDEF01“, GPT esetén {CDEA7BCF-BC8B-426B-91B1-CDE0CF2DE33A} formátumban), kötetekről beszélve a GUID lesz a számunkra érdekes. Ennek képzése során MBR-nél csak a “DiskID”, GPT esetén a “PartitionID” is részt vesz a kiszámolásában – de most nem ez a cikk témája.

A lemezek azonosítóját valóban a legegyszerűbb módon diskpart segítségével tudjuk lekérdezni:

sel disk 0

detail disk (vagy uniqueid disk – ha csak ez érdekel)

Egy merevlemezen lehet egy vagy több partíció, ezekre is használhatjuk az előbbi programot (detail partition), de bennünket a kötetek érdekelnek – erre viszont ez az alkalmazás nem megfelelő.

Nézzük a másik eszközt, amit használtak: maga a mentő-program által (szerintem feleslegesen) felajánlott lehetőség, ami szintén lemezeket, nem köteteket listáz:

wbadmin get disks

Mivel GPT-t használtak, nem tűnt fel, hogy ennek is az eredménye a DiskSignature (mellékesen MBR esetén is GUID-szerűen listáz ez a parancs, az első 8 karakter után feltölti nullákkal). A két lekérdezett adat egyezett (természetesen, hiszen mindkettő lemezekre vonatkozott), ezért a kapott azonosítóval dolgoztak tovább.

Akkor most nézzünk két helyes megoldást is, a korrekt GUID kiolvasására:

mountvol

vagy

GWMI -Namespace root\cimv2 -Class win32_volume | fl -Property Label,DriveLetter,DeviceID,SystemVolume,Capacity,Freespace

A végére még egy apró infó: a cikk eredeti céljához használt hivatkozásban a \\?\ célja, hogy kikapcsolja a path parsing-ot. Alapból megszoktuk NT-től (kb. Vista-ig), hogy az útvonal hossza 255 karakter lehet, ilyen formátumban a nagykönyv szerint elmehetünk egész 32.767 karakterig.

Kategóriák:General Címkék: , ,