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

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.

GPP több-opciós ablakok

Azt tapasztalom, hogy még mindig nem mindenki jártas a GPP azon esetében, amikor pl. a Control Panel szekcióban a regionális beállításokat kell kezelni (ahol több mindent tudunk szabályozni). Az nem elég, ha beállítjuk a kívánt formátumot/értéket, hanem “aktiválni” is kell (erre utal az alapértelmezett piros aláhúzás is).

Ehhez a következő billentyűkombinációkat kell ismerjük:

F5: az aktív fülön mindent aktivál

F6: az aktuálisan kijelölt sort aktiválja

F7: az aktuálisan kijelölt sort deaktiválja

F8: az aktív fülön mindent deaktivál

Abban az esetben, ha elég egy módosítást kiszórnunk, úgy a többi maradhat piros színnel aláhúzva (ez a “Not configured” állapotnak felel meg).

Morfondírozás

Egy ismerősöm hívott fel a napokban azzal, hogy a cég, ahol dolgozik, zsarolóvírus áldozata lett. Voltak mentések, de azokat egy folyamatosan felcsatolt USB-lemez képezte, így azt is titkosította a kártevő.

Sajnos olyan fertőzés volt, amire nincs ellenszer (sajnálatos módon ilyenek vannak többségben). Szakmai véleményemen kívül, hogy valami még menthető-e, a beszélgetés során felmerült a fizetés kérdése. Jeleztem, hogy nem javasolt fizetni – még akkor sem, ha a cég minden digitális anyaga odaveszett.

Ha megnézzük a technikai vonalat, találunk bőven kifogásokat: olyan rendszergazdájuk van, ami a tulajdonos egyik megbízhatónak tekintett embere, viszont aki szakmailag nem haladt a korral. Bár csak az ismerős elbeszélése alapján kaptam némi képet a cég informatikai állapotáról, már az beszédes volt, hogy a “szerver” egy billentyűzet-egér-monitor mentes Windows XP volt, ami a sarokban porosodott, senki nem mert hozzányúlni, teljes mértékben “fekete dobozként” volt kezelve. Van olyan cégem, ahol bizonyos okok miatt szükséges 32-bites oprendszer futtatása – no de nem az a “fő” kiszolgáló, s próbálom minimálisra csökkenteni a kitettségét is.

Érdekességként még annyi, hogy pont a rendszergazda javaslatára (említettem, hogy megbízható?) a tulajdonos (aki eleinte szintén nem akart fizetni) a bűnözővel elkezdett levelezni, aminek következtében sikerült megállapodni egy jóval kisebb összegben a feloldókulcsért cserébe – majd, amikor az utalásra került, a zsaroló meggondolta magát, s további összeget követelt – amit szerencsére már nem kapott meg…

Egy fontos WSUS beállítás

Egy “kerekasztal”-beszélgetés során derült ki egy apró, de annál fontosabb információ: még mindig nem jutott el mindenkihez egy WSUS-beállítás szükségessége.

A WSUS-t használók alapvetően két csoportra oszlanak. Az egyiknél be van állítva, hogy az új frissítések letöltése után automatikusan bizonyos foltok telepítésre engedélyezettre váltsanak, a másik csoport minden javítást egyesével engedélyez. Főleg az előbbi esetén merülhet fel az a csalóka hit, hogy minden gép rendben van, minden naprakész – hiszen a Wsus konzolon minden zöld, utóbbiak esetén az tűnhetett fel, hogy kevesebb frissítést kell engedélyezni egyes gépek esetén.

Az ok az, hogy a 1903 verziótól kezdve a Microsoft áttért a Unified Update Platform (UUP) fantázianevű frissítési módszerre. A kommunikáció alapján ez egyszeri beállítás, elvileg nem fog kelleni minden nagyobb Feature Update után.

Ennek következménye az, hogy bár a 1903-as verziójú Windows változat (illetve bármely előző verzió+foltjai) WSUS-ra történő letöltéséhez és kiszórásához elég volt az eddigi beállítás, a 1903-ra érkező javítások addig nem fognak látszani (ezáltal nem is tudjuk engedélyezni), amíg a beállítások közt nem engedélyezzük az alábbi pipát:

Amennyiben nincs régebbi Windows 10 verziónk, az alatta található pipa kikapcsolását érdemes körbejárni, mert pl. a Windows Malicious Software Removal Tool is abba esik bele.

VM nem indul automatikusan

Adott helyen felmerült a kérdés, hogy egy adott VM miért nem indul el automatikusan, amikor a host-ot újraindítják. A srácok nem igazán értették, ezért a mélyebb megértéshez elővettük az Application naplót, konkrétabban a Microsoft/Windows/Hyper-V-Worker/Admin eseménytárat, abban az alábbi megjelenő 4 hibaüzenetet (időrendi sorrendben alább):

12162: ‘VM’: Failed to configure ‘D:\Hyper-V\Virtual Hard Disks\VM.vhdx’: The storage where the virtual hard disk is located does not support virtual hard disk sharing.

12140: ‘VM’: Failed to open attachment ‘D:\Hyper-V\Virtual Hard Disks\VM.vhdx’. Error: ‘A virtual disk support provider for the specified file was not found.’ (7864368). (Virtual machine ID 6DF70F48-0492-4F78-B6D1-4A6BE05DA167)

12010: ‘VM’ Microsoft Emulated IDE Controller (Instance ID 83F8638B-8DCA-4152-9EDA-2CA8B33039B4): Failed to Power on with Error ‘A virtual disk support provider for the specified file was not found.’ (0xC03A0014). (Virtual machine ID 6DF70F48-0492-4F78-B6D1-4A6BE05DA167)

12030: ‘VM’ failed to start. (Virtual machine ID 6DF70F48-0492-4F78-B6D1-4A6BE05DA167)

Ami furcsa, hogy mivel Gen1-es gép boot-lemezéről van szó, ezért értelemszerűen csak IDE-s vezérlő jöhet szóba, s természetesen arra is van kötve (virtual hard disk sharing pedig csak scsi csatoló esetén jöhet szóba). Ugyanakkor feltűnhet, hogy a másik hibaüzenet az, hogy nem találja az állományt.

Akkor gondoljuk végig. Amennyiben kézzel indítjuk a virtuális gépet, akkor csont nélkül elindul – tehát az állomány létezik, van elég jogosultság hozzáférni. Nézzük, akkor melyik köteten van, valamint van-e még másik VM boot ugyanitt: igen, van, az pedig automatikusan el is indul.

Igen ám, de a kötet milyen lemezen van? Nos, egy iscsi LUN-ról beszélünk, tehát még az is lehet, hogy azért nem találja a kötetet (s ezzel együtt az állományt), mert még nincs felcsatolódva, amikor elindul a VM. Ennek az elméletnek igazolása után meg is fejtettük a dolgot, egy kérdés maradt még hátra: ha ez így van, akkor a másik VM (ugyanerről a kötetről) miért indul el? Erre megkaptuk a választ, amint belenéztünk a beállításokba: azért, mert az 120sec-es időkésleltetéssel volt indítva.

A probléma feltárva, a megoldást már a srácokra bíztam (ezt is késleltetik, átteszik másik kötetre, stb), pipa 🙂

A megszokás/kényelem nagy úr vs 1903

A (várhatóan következő hónapban) megjelenő 1909 előtt (ami “csak” egy szervízcsomag lesz), összefoglalom a környezetemben tapasztalt véleményeket a 1903-al kapcsolatosan.

• MS-nél is rájöttek, hogy telepítés után az elsők között van a 1709-ban bevezetett “People” eszköztár kikapcsolása, szinte senki nem használja. Ezt így szerencsére száműzték. Hogy ne maradjunk “kikapcsolandó” nélkül, megkaptuk a keresés opciót, most a legtöbb ügyfelet az zavarta, annak kiiktatása volt az első kérelmek között
  
• elég sokan megszerették a bejelentkezési képernyő változó, valóban minőségi háttereit. Nos, az aktuális verzióban ez alapból homályos (mondjuk az okát nem igazán értem) – szerencsére ez is könnyen orvosolható, a Settings/Personalization/Colors/Transparency effects menüpont Off-ra állításával (vagy GPO, vagy registry – ki melyiket szereti). Ez természetesen mást is érint, erre érdemes figyelni.
  
• végül, de nem utolsó sorban a cikk címét inspiráló képesség, a már Windows 7-ben létező “Plan brightness” (nem összetévesztendő az “Adaptive brightness” funkcióval, mi arról szól, hogy egy érzékelő segítségével a környezet fényerejét mérve a kijelző megvilágítása is automatikusan változik). Előbbi lehetőség viszont azt teszi lehetővé, hogy kétféle képernyő-fényerőt lehet beállítani: egyet, amikor áramba van csatlakoztatva az eszköz, s egy másodikat, amikor akkumulátorról üzemel (ez ugye a telepről való működés idejének kitolása végett). Nos, ez megszűnt, mostantól egy fényerőnk van. Igen, tudom, hogy a “Notifications”-höz kikerült a szabályozó csúszka, meg léteznek Fn+Fx billentyűkombinációk – de az mégsem ugyanaz, mint ahogy beavatkozás nélkül ez automatikusan változott. Igen, azt is tudom, hogy néhány felhasználót zavart, hogy a két említett fényerő nem volt egyforma – de ők legalább ízlés szerint beállíthatták, akár maximálisra mindkét értéket. De most megszűnt ennek a lehetősége is – amit azért is furcsállok, mert akárhogy vesszük, a hordozható eszközök aránya jelentősen nőtt…
  

AD és O365

Aktuális történetem szintén AD-ról szó, bár ez érdekes módon most Exchange-problémából indult. Igen, természetesen tudom, hogy az Exchange az AD-ra épül – de azért mégis két külön termék.

Adott egy elég nagy szervezet, több tartománnyal, több Exchange kiszolgálóval. Egyes helyeken a levelezést már kiszervezték O365-be, míg más tartományok maradtak a hagyományos Exchange-verziónál (ami ráadásul most van migráció alatt, egy újabb verzió kerül bevezetésre – de jelen esetben ez lényegtelen).

A gond ott merült fel, hogy bizonyos tartományokból nem lehetett másik tartománybeli felhasználóknak emailt küldeni, „A postaláda címzettjének nincs postaláda-adatbázisa.” hibaüzenettel eldobta – s itt most csak a „belső” („testvér”) tartományokra gondolok.

Szokás szerint a helyzet nem volt ennyire egyszerű, ugyanis első információk szerint csak egy tartomány volt, amelyik nem tudott a cél-tartományba küldeni, miközben minden más irányba csont nélkül kimentek a levelek.

Kezdjük az elejével. A hibaüzenet alapján látszott, hogy a cél-tartományban (amelyik ráadásul O365-be költözött) nem történt meg minden lépés a migráció során, konkrétan a felhasználók TargetAddress címe nem lett kitöltve. Ha ez viszont igaz, akkor miért csak egy tartományból pattannak vissza a levelek? Utánajárva, letesztelve, kiderült, hogy ez csak feltételezés volt – ugyanis máshonnan nem küldtek levelet a cél-tartományba, ezért feltételezték, hogy akkor mindenki rendben tud küldeni. Amint másik „testvér” próbált emailt küldeni, természetesen ott is jelentkezett a hiba.

Rendben, akkor tehát a megoldás a TargetAddress kitöltése. A kollégák elvégezték a feladatot, majd újabb tesztek következtek. Nos, ekkor már valóban teljesült az előző állítás: csak egy (az eredetileg is jelzett) tartományból voltak sikertelenek a küldések, a többiek rendben tudtak küldeni.

Pontosabban, az előző mondatom sem teljes. Ugyanis ki kell egészíteni egy „általában” szócskával a mondat első felét. Volt, amikor sikeresen megérkezett a levél, volt, amikor nem (s ebben az esetben ugyanezzel a hibaüzenettel akadt el). Ugyanattól a feladótól, ugyanannak a címzettnek.

A nyomozás során újra átnéztem minden beállítást, értéket. ADSIEdit volt egyik fő eszközöm, de mindegyre meggyőződtem róla, hogy bármelyik DC-re is csatlakozom a hibás tartományból, annak GC partíciója (hiszen az tartalmazott infót a testvér-tartományról) helyes értékeket ad vissza a címzettről.

Aki ismer, tudja, hogy nem adom fel egykönnyen. Nos, ebben az esetben is elég komolyan foglalkoztatott a történet, szinte éjjel is ezzel aludtam 🙂

A megoldást egy véletlen hozta el. A „hibás” tartományban a kollégák felvettek egy új felhasználót, email-fiókkal, ahogy illik – de röviddel rá eltűnt a postaláda. Jelezték felém, hogy a Bermuda-háromszög ide költözött, így megkértek, hogy próbáljam én helyretenni a fiókot. Amikor elkezdtem utánajárni, akkor egy hirtelen ötlettől vezérelve megpróbáltam RDP-vel rámenni a DC-kre. Egyikre csont nélkül csatlakoztam, a másik… hát az elfogadta a név/jelszót, de utána nem történt semmi. A kollégát kértem, hogy próbálja ő – neki sem sikerült. A furcsa az volt, hogy mmc-vel, adsiedit-el csont nélkül tudtam rá csatlakozni. Kértem, hogy mindegy, milyen módon (ha lehet, „rendesen”, ha nem, akkor bárhogy) indítsák újra a DC-t – s utána érdekes módon minden megjavult.

Utólag persze könnyű okosnak lenni. A hibás email-küldés azért volt véletlenszerű, mert annak függvényében, hogy melyik DC-től kérdezte le a címzettet, kapott/nem kapott jó adatot. Igen, ennek ellentmond az, hogy a rossz DC is már tartalmazta a jó címet (hiszen más módon lekérdeztem tőle), de hogy mitől volt mesebeli (adott is, meg nem is; működött is, meg nem is)… A szokásos „indítsd újra” megtette a hatását 🙂