Nyilvános mappák maradvány objektumai

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

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 🙂

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

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

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.