Archívum

Archive for the ‘Exchange’ Category

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

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ő 🙂

AD és O365

július 31, 2019 1 hozzászólás

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 🙂

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

Egy rossz tervezés

április 25, 2019 Hozzászólás

Mivel máshol is belefutottam, gondoltam leírom, hátha van, aki legalább ezt olvasva észbe kap… Volt egy projekt, amelyben a segítségem kérték, egy teljes migrációt kellett végrehajtani a régi szerverekről az újakra. A kliens ugyanakkor nem minden fázist adott át, többek között a mentést és annak beállítását házon belül tervezte megoldani.

A sikeres migráció végéig még mindig nem döntötték el, hogy milyen módszerrel, milyen adattárolóra, milyen rendszerességgel fog történni a mentés. Abban egyetértettünk, hogy ez mindenképp szükséges, de mivel továbbra is saját maguk akarták kivitelezni, nem erőltettem a dolgot.

Szerencsére most nem azzal folytatom, hogy egy kripto-vírusos támadás után nem volt hova nyúlni. Viszont egy másik dolog következett be: a levelező-kiszolgálónak szánt lemezek teltek meg. Az előre egyeztetett elképzelés szerint nem körkörös loggolást használnak (ha lehet, amúgy sem ez a javasolt), ez viszont azzal jár, hogy ha nincs teljes mentés (s itt külön cikk lehetne a mentések típusairól, a piacon található mentőszoftverek módszereinek elnevezéséről), akkor a naplók csak gyűlnek. Ha nem monitorozzuk (akár külön szoftverrel, ami riaszt, akár manuálisan), az emailezési szokásoktól függően elég hamar meg tudják tölteni a rendelkezésre álló területet – amikor is a levelezés megáll. Vannak ugyan beépített korlátok az Exchange-ben, hogy bizonyos szint alá ne engedje megtelni a lemezt, de ezen korlátok elérésekor is lehetnek kellemetlenségeink az email-forgalomban. Helyette a javaslat az, hogy minden esetben tervezzük meg a mentést is (adott cégnél “csak” a levelezés állt le, mert az adatoknak, adatbázisoknak volt elég hely – de azok mentése is szükséges!).

Sajnos még mindig nem mindenhol fordítanak kellő figyelmet a mentésekre. Lehetne azt mondani, hogy cégmérettől függ – de nem igaz. Egy kis cégnél is láttam helyesen beállított mentést – ez a (magyarországi viszonylatban) közepes cég viszont nem rendelkezett ilyennel. Amikor felhívtak, hogy nem megy a levelezés, s megtaláltuk a “hiba” okát, fokozottan jeleztem nekik, hogy ez miből eredt, újból megígérték, hogy beállítják a mentést – majd bizonyos idő múlva, amikor ismét megkerestek, ugyanezzel a problémával, akkor már szerencsére hajlottak rá, hogy közösen átbeszéljük és kivitelezzük a végleges megoldást.

Send connector gondolatok

március 28, 2019 2 hozzászólás

Bár mostanában kicsit el vagyok havazva néhány nagyobb migrációval, egy-két apró segítségkérés megoldását próbálom beszorítani az időmbe.

Egyik helyen kértek, hogy nézzem át a levelezés beállításait, ugyanis egy redundánsra elképzelt környezetben pont a redundancia hiányzott – konkrétan sem a levélküldés, sem a levélfogadás nem működött, külső partnerek irányába. A DAG működött, tehát a kliensek tudtak csatlakozni a postafiókhoz, belső levélküldés rendben volt, de szerették volna, ha valóban magas rendelkezésre állást alakítunk ki.

A fogadás témakörét néhány alapbeállítás hiánya (másodlagos MX, tűzfal-beállítás) kimerítette, a küldésnél viszont akár ennek, de leginkább ennek a cikknek az olvasása hiányzott. Létezett ugyan két Send connector, mindegyiknél a “Source” szervereknél ki volt töltve az elképzelt konfiguráció alapján – ettől függetlenül, amikor az elsődleges kiszolgálót leállítottuk, a küldés továbbra is az “ő” küldési csatlakozóján akart kimenni. Természetesen a kiszolgáló leállított állapotában az sem tud küldeni, így a levelek csak gyűltek – az ügyfél és a kollégák pedig értetlenkedtek.

A megoldást többféle módon próbálták megtalálni, ezekből szemezek.

Egyrészt, minden csatlakozón kipróbálták a “Scoped send connector” bekapcsolását. Nos, ez valóban az egyik helyes megoldás, bizonyos feltételekkel: amennyiben a tartományban ki vannak alakítva telephelyek, megfelelő ip-címtartománnyal, s a levelező-kiszolgálók különböző telephelyek tagjai. Ebben az esetben ugyanis csak a saját telephely (és a “Scope” által nem védett) küldési csatlakozóit látja a kiszolgáló, nem fogja használni a “másik” csatlakozóját. Jelen esetben nem volt telephelyes kialakítás, így ennek a pipának a ki/be kapcsolt állapota semmit nem jelentett.

A másik próbálkozás a súlyozásra (költség) irányult. Nos, itt hivatkozok vissza az előbbi cikkre – ugyanis tekintettel arra, hogy a fő telephelyhez elképzelt csatlakozó költsége kisebb volt, mint a második telephelyé, mindig ő lett a kiválasztott. Az, hogy a kiszolgáló épp nem működött, nem zavarta az Exchange-t… Amint egyenlő költséget állítottunk be, a kiválasztási folyamat továbblépett, lehetővé téve a második kiszolgáló csatlakozójának használatát.

Egy másik megoldás, amit mondjuk nem próbáltak, az MX-rekordok alapján történő küldés (ez ugye akkor járható, ha nem DNS-alapú címkeresés történik, hanem smart host-nak küldik). Ekkor felvesszük minkét smart-hostot 1-1 A rekordba, majd azonos névvel, de különböző súlyozással felvesszük a két MX rekordot (egyik mutat egyik A rekordra, másik a másikra).

A megoldások sora tovább folytatódhat, de gondolatébresztőnek ennyi elég…

Minimális keresési karakterszám a GAL-ban

december 14, 2018 Hozzászólás

Adott helyen egy olyan probléma merült fel, hogy „régebben” jól működött az Exchange címtárban a keresés, viszont egy ideje nem megy. Pontosítva a megfogalmazást, kiderült, hogy azokra készülékekre vonatkozott a megállapítás, amelyek ActiveSync-et használnak.

Körbejárva a kérdést, a háttérben az van, hogy Exch 2007-től alapértelmezetten 4 karakter alatt nem megy a keresés a GAL-ban. Ez Exch 2003-ban még 2 karakter volt, tehát ez egy új „feature”, nem bug 😊

Szerencsére ez módosítható: http://terenceluk.blogspot.com/2013/12/unable-to-search-gal-with-less-than-4.html

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

Exchange 2019 morgás

október 25, 2018 6 hozzászólás

Ugye a napokban lett véglegesítve az Exchange 2019. Eddig még lehetett reménykedni, hogy az előzetes információkkal ellentétben még van esélyünk a cikket kiváltó morgás megszűnésére, de a remény elhalt… Ugyanis szép és jó a fejlesztés, de egy dolgot emelnék csak ki belőle: a Mailbox kiszolgáló minimálisan ajánlott 128 GB memóriáját. Az MS-nél vagy nagyon elgurult a gyógyszer, vagy ezzel akarják a kkv-kat az Office365 irányába terelni.

Egyik érintett kis cég, ahol a napokban beszéltünk fejlesztésről, kapásból kilőtte ezt a verziót. Mivel vidék, rossz internet-eléréssel, ráadásul nagyon (értsd: nagyon) kis költségvetésű cég, az O365 is kilőve – így maradtunk az Exchange 2016 bevezetésénél.

Aki ismer, tudja, hogy amennyire lehet, MS-párti vagyok, ugyanakkor szakmai szempontból is meg szoktam mondani a véleményem – ennek kapcsán ez a lépés több fekete ponttal felérő minősítést ér… Csak ismétlésként, az eddigi minimális követelmények:

– Exchange 2019: 128 GB

– Exchange 2013, 2016: 8 GB

– Exchange 2010: 4 GB

 

Out-of-office on Distribution Group

július 24, 2017 5 hozzászólás

Még régebben feltettek nekem egy kérdést, amit érdemesnek tartok egy eszmefuttatásra: miként lehet egy disztribúciós csoporton beállítani automatikus választ?

A kolléga eredeti ötlete az volt, hogy a levél-tippet használja fel (felhasználóknál a beállítás Fájl / Beállítások / Levelek / Email tippek szekció). Nos, az Outlook 2010-től használható email-tipp jellemzően* belső címzett esetén jelenik meg, s arra használható, hogy a feladó kiválasztása után, de még a levél elküldése előtt értesüljünk a címzett állapotáról. Pontosabban, ha az illetőnél be van kapcsolva a “Házon/magán kívül” állapot, akkor az ott megadott szöveg lesz látható még a levél elküldése előtt, illetve, ha tagja valamilyen csoportnak, akkor a csoporton beállított MailTip is látszik.

(* bizonyos, jól meghatározott esetekben külső címzett is, pl. érzékeny információ küldésekor).

Az eredeti kérdésre a választ több módon oldhatjuk meg, példaként 1-1 szerver-oldali, illetve fiók-szinten megvalósított ötletet írok, a teljesség/mélység igénye nélkül (no meg 3rd party megoldások kihagyásával).

A Transport Rule estén a szerveren hozunk létre egy szabályt, de annak formátuma (illetve az SMTP-kódja) nagyon hasonló a hibaüzenetekhez, még akkor is, ha saját hibaüzenetet teszünk be (most maradjunk az egyszerű rgazda szinten), ezért ezt – főleg kezdőknek – nem javaslom.

Fiók-oldalon sokkal elegánsabb megoldási lehetőségünk van, erre például egy dedikált fiókot hoznék létre – ő már tud OoO üzenettel válaszolni (ne feledjük, ez feladónként napi 1 üzenetet eredményez), az általa kapott leveleket pedig automatikusan továbbítani a csoportnak (akár úgy, hogy neki lokálisan is maradjon egy példány, naplózási céllal).

Sokan felkaphatják a fejüket, hogy de ők láttak az elosztási csoportokon olyan pipát, ami OoO-val kapcsolatos. Igen, a régebbi Exchange-ken az Advanced fülön grafikusan ki volt vezetve egy ilyen pipalehetőség („Send Out-of-office message to originator”), de ez csak arra való, hogy a tagok bármelyikén beállított OoO üzeneteket az eredeti feladónak küldje, ne a csoportnak szórja szét. Ha ez megfelelőnek tűnik az eredeti probléma megoldására, számítsunk rá, hogy nem biztos, hogy mindenki egységesen állítja be az ilyen üzeneteket, illetve, amennyiben a csoportból többen beállítottak maguknak saját OoO üzenetet, a feladó mindenkitől megkapja.

Az újabb Exchange-ken a grafikus kivezetés helyét a PS vette át:

Get-DistributionGroup * | Set-DistributionGroup -SendOofMessageToOriginatorEnabled:$true

Amennyiben még tovább bonyolítjuk a kérdést, s szeretnénk képet betenni: nos, ezt nem támogatja az OoO. Ha mégsem bírjuk ki, akkor Outlook segítségével létrehozunk egy szabályt, ami egy olyan sablonra mutat, amelyik megfelelően elő van készítve – de ez már tényleg túlmutat a cikk keretein 🙂

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