Archívum

Archive for the ‘General’ Category

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: , ,

GPP több-opciós ablakok

december 19, 2019 1 hozzászólás

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

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

Morfondírozás

november 30, 2019 3 hozzászólá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…

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

Egy fontos WSUS beállítás

október 25, 2019 Hozzászólá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.

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

VM nem indul automatikusan

szeptember 25, 2019 Hozzászólás

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

augusztus 26, 2019 1 hozzászólás

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…

Egy apró „fejlődési” hiányosság

május 30, 2019 1 hozzászólás

Nemrég egy sérült AD-t kellett rendbetennem. Most nem térek ki, hogy a két sérült AD-partíció javítása sem volt egyszerű (az külön megérne egy cikket), helyette az AD-hoz tartozó file-replikációt veszem górcső alá.

Aki még nem foglalkozott vele, annak kezdem az elejével. A tartományvezérlők a feladatuk elvégzése során elég sok feladatot kezelnek – pl. tudjuk, hogy az egész AD egy jó, működőképes DNS nélkül nem ér semmit. No de a DNS nem minden. Ritkán, de előfordul, hogy maga az AD-adatbázis sérül meg (ez tartalmazza a partíciókat), illetve még egy fontos része van: a házirendeket és scripteket tartalmazó Sysvol mappa replikációja.

Ez a replikáció két módon történhet. Egyrészt van a régi, “hagyományos” NT-korszakbeli LAN Manager Replication Service-t váltó FRS (File Replication Service), másrészt az új, 2003 R2-ben bevezetett, de 2008-ban kiteljesedő DFSR (DFS Replication). Manapság, ha új tartományt építünk, alapértelmezés szerint ez utóbbi lesz használva, de régebbről “görgetett” tartományok esetén is tudunk váltani (ehhez minimum 2008-as tartományi-szint szükséges). Sőt, Windows Server 2016 RS3 (1709)-től már az FRS egyáltalán nem támogatott.

Az áttérés nem nehéz, arra érdemes figyelnünk, hogy mindig legyen szinkronban a tartományunk (amennyiben egyik DC nem értesül adott áttérési műveletről, utólag megpróbálja “utolérni” a többieket – akkor van gond, ha bármilyen hiba bekövetkezik).

Visszatérve, a jelzett helyen elég gáz helyzet volt. Mivel nem akartam/akarták a teljes AD-t újrahúzni (jogosan), a már említett adatbázis javítása után következett a replikáció helyretétele. Igen ám, de ekkor derült ki, hogy még FRS-t használnak, így ezt a vonalat elengedve, az a döntés született, hogy akkor most térünk át DFSR-re. Általánosságban a javaslat az, hogy előbb a hibákat hárítsuk el, s egy egészséges környezetben változtassunk – de jelenlegi helyzet egyike a ritka kivételeknek, ahol ezt könnyebb volt meglépni.

A két replikációs módszer összehasonlítását már megtette más – én arra próbálok mindenkit rávenni, hogy egy hozott/kapott, de akár saját “görgetett” tartomány esetén is, amennyiben lehetséges, lépje meg ezt a lépést. Erre utal a cím is, hogy a cég fejlődik, az AD séma változik – de tervezzük bele a replikáció váltását is, egy hibakeresés esetén saját magunk munkáját is megkönnyítve 😉

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