Archívum

Archive for the ‘Exchange’ Category

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

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

Exchange mentések vs Hyper-V

szeptember 15, 2016 Hozzászólás

Adott helyen egy VM (történetesen egy Exchange) átkerült egy 2012-es gazdagépről egy 2012 R2-t futtató gépre. A mozgatás után látszólag minden rendben működött, így a rendszergazda kollégák nem bolygatták többet.

Egy bizonyos idő eltelte után a szerver nem volt hajlandó fogadni a leveleket, a monitorozó-rendszer erőforráshiányra panaszkodott. Megnézve a paramétereket, a kollégák egyből kiszúrták, hogy itt bizony merevlemez-kapacitás hiányzik, s tudjuk, hogy az Exchange-be épített Back-pressure hatására inkább visszautasítja a levelek fogadását, mint veszélyeztesse „saját épségét”. Tüneti kezelésként gyorsan felszabadítottak némi helyet, de természetesen nem hagyták annyiban a dolgot, biztos, ami biztos alapon segítséget is kértek.

Utánajárva, hogy miért lett tele a kötet, kiderült, hogy a naplók törlése nem történt meg (ez akkor történik meg, amikor egy teljes mentés készül az Exchange-ről). Kiderült, hogy magán a levelező szerveren nem volt beállítva mentés, de a gazdagépen viszont igen, mégpedig a teljes VM mentése. Ez „triggerelni” szokta az Exchange-logok törlését is, itt viszont nem történt meg. Az okot keresve elég hamar rátaláltunk, hogy mikor volt az utolsó teljes mentés (Exchange-konzol segítségével kiolvasható), majd mivel a jelzett dátum körül történt a mozgatás, nyilvánvalóvá vált, hogy ezzel függ össze. Szerencsére a gazdagép Hyper-V konzolját megnyitva egyből látszott a probléma: az Integration Services (itt írtam róla legutóbb) nem volt naprakész. A friss, 2012 R2-s kiegészítőket telepítve, majd a VM-et újraindítva a következő mentés egyből ismét helyreállította a rendet.

Office 2016 gondolatok

november 6, 2015 6 hozzászólás

Az új Outlook 2016 sok embernek fog fejfájást okozni. Az ok egyszerű: Exchange kiszolgálóhoz csak akkor fog tudni csatlakozni, ha rendesen be van állítva az autodiscover szolgáltatás. Mielőtt ezt részleteznénk, nézzük a manuális lehetőségeket: vagy Outlook.com, illetve más Exchange ActiveSync (EAS)-kiszolgáló, vagy Pop/Imap kiszolgáló. Az EAS nem használható Exchange esetén, ugyanis az EAS-protokollt is tervezik kivezetni (miután az Outlook.com-ot átteszik Exchange-alapúra), helyette az OutlookAnywhere használata javasolt. Az idők folyamán így alakultak a lehetőségeink (teljesség igénye nélkül):

Outlook 2003: outlook2003

Outlook 2010: Outlook2010

Outlook 2013: outlook2013

Outlook 2016:outlook2016

Mivel manuális lehetőségünk nincs, nem marad más hátra, mint a levelezés automatikus beállítása. Ahhoz, hogy ez működjön, már Exchange 2007 óta velünk van az Autodiscover lehetőség – még ha eddig nem is mindenki használta.

No de miről is szól ez? Nagy vonalakban: a kliens kiküld egy igényt, mely szerint szeretne adott tartomány CAS-kiszolgálójához csatlakozni, erre kap egy választ, ami alapján „bekonfigurálja” magát (halkan megjegyzem, ez most tényleg nagyon konyha-nyelven volt elmondva). Ahhoz, hogy ez működjön, természetesen a minimum a jól beállított Exchange-kiszolgáló – s itt máris elakadtunk, hiszen az önjelölt rendszergazdák számára a levelezés beállítása kimerül a ki/bejövő forgalom megvalósításánál. Ha ezt az akadályt vettük, akkor még tanúsítvány(ok), illetve a DNS-nevek megfelelő beállítása van hátra.

Nem tartom kizártnak, hogy az új, 2016-os Office terjedése kapcsán nőni fog a „piros gombos” hívások száma, hiszen elég sok helyen a kiszolgáló alap-beállításokkal fut. S akkor még nem beszéltem arról, amiről már egyes kollégák is írtak, hogy Outlook-foltozás volt szükséges bizonyos Exchange-kiszolgálókkal való együttműködéshez.