Archívum

Archive for the ‘Exchange’ Category

Exchange Y2K22 hiba

január 1, 2022 5 hozzászólás

A Microsoft (s elsősorban az Exchange 2016/2019) fejlesztői sokat fognak mostanában csuklani, mivel a világon nagyon sok rendszergazda miattuk fogja az új évet hibakereséssel kezdeni.

A gond ott van, hogy a levelek beragadnak a kimenő sorba, „Message deferred by categorizer agent” hibaüzenettel. Az ok az, hogy az „MS Filtering Engine Update” megkapta a legújabb, “220101001” verziószámú (később a 02 végű) frissítését – viszont a verziószám tárolására használt változóban a „22” kezdetű érték már nem fér el (a pontos technikai részletek – signed long/unsigned long – már nem a cikk témája).

A megoldás aránylag egyszerű: kikapcsolni (Disable-AntiMalwareScanning.ps1) vagy átlépni a malware-szűrőt:

Set-MalwareFilteringServer -BypassFiltering $True -identity <Kiszolgálónév>

A Microsoft Exchange Transport újraindítása után szépen elindulnak a levelek 😊

Update: Javítás itt: https://techcommunity.microsoft.com/t5/exchange-team-blog/email-stuck-in-exchange-on-premises-transport-queues/ba-p/3049447

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

Exchange vs AD-séma

december 25, 2021 Hozzászólás

Nemrég egyik olvasóm megkeresett, hogy segítsek neki, mert a séma-verziókról szóló cikkem segített neki, de az ott található linkek elavultak/érvénytelenek, a verziószámokról nem is beszélve.

Azóta valóban sok víz lefolyt a Dunán 🙂 Az AD-sémák felsorolásától most eltekintenék, a kolléga inkább Exchange-oldalról közelítette meg a témát. Nos, annak lekérdezését is frissítsük akkor, hiszen PS-ből csodálatosan lekérdezhető:

Import-Module ActiveDirectory

# Exchange Schema Version (forest)

$sc = (Get-ADRootDSE).SchemaNamingContext

$ob = “CN=ms-Exch-Schema-Version-Pt,” + $sc

Write-Output “(Forest Exch schema) RangeUpper: $((Get-ADObject $ob -pr rangeUpper).rangeUpper)”

# Exchange Object Version (forest)

$cc = (Get-ADRootDSE).ConfigurationNamingContext

$fl = “(objectClass=msExchOrganizationContainer)”

Write-Output “(Forest Exch object) ObjectVersion (Configuration): $((Get-ADObject -LDAPFilter $fl -SearchBase $cc – pr objectVersion).objectVersion)”

# Exchange Object Version (domain)

$dc = (Get-ADRootDSE).DefaultNamingContext

$ob = “CN=Microsoft Exchange System Objects,” + $dc

Write-Output “(Domain Exch object) ObjectVersion (Default): $((Get-ADObject $ob -pr objectVersion).objectVersion)”

Ha viszont csak a pőre számok érdekelnek bennünket, itt található egy aktuális lista (mondjuk más sorrendben, mint a fenti lekérdezés, de a kiíratásnál betettem az itt használt megnevezést is).

Ha pedig arra vagyunk kíváncsiak, hogy melyik Exchange CU esetén változik a séma, itt (2016 esetén itt) kapunk rá választ.

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

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