Archívum

Posts Tagged ‘exchange’

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

Exchange 2010 SP3 UR2

augusztus 19, 2013 3 hozzászólás

A múlt héten, kedden kijött frissítések (legalábbis a címben említett folt biztosan) megmutatták, hogy miért jó megfontoltan telepíteni a javításokat. Legalábbis azon kollégák egy részénél, akik rendelkeznek a piros gombbal, páran máris jelezték segítségbeli igényüket.

A gond ugyanis az, hogy a megszokottól ellentétben az említett folt igényli az SP3 telepítőt. Ha ezt automatikusan nem találja, illetve a telepítés során nem mutatjuk meg neki (pl. automatikusan Wsus-ról próbál települni), akkor  Error 8024002D hibaüzenettel sikertelen telepítésnek lehetünk tanúi:

Exch2010SP3UR2

Nem kell megrémülni, a szokott helyről letöltve az SP3-at, kicsomagolva, majd újraindítva a telepítést sikeresek lehetünk. Sőt, ha nem akarunk azzal bajlódni, hogy megmutassuk a telepítőnek a szervízcsomag helyét, csomagoljuk ki egyből abba a könyvtárba, ahol az várja. Ennek lekérdezése az alábbi paranccsal történik:

Get-ItemProperty “HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{4934D1EA-BE46-48B1-8847-F1AF20E892C1}” | Select InstallSource

A kicsomagolás után ráengedjük a foltot, majd hátradőlhetünk…

p.s. a folt telepítése utáni újraindítást követő ellenőrzésre (mint itt írtam, nem jó a szokásos Get-ExchangeServer) használhatjuk vagy a már hivatkozott cikkbeli Névjegy-et, vagy az alábbi parancsot:

GCM exsetup |%{$_.Fileversioninfo}

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

Exchange Send as… jog

október 26, 2012 8 hozzászólás

Exchange 2010 környezetben abban kérték a segítségem, hogy egy megfelelő jogosultságú fiókkal próbálták egy másik fióknak a „Send as…” beállításait módosítani, s az hibával elhasalt:

Error:

Active Directory operation failed on Server.Domain.hu. This error is not retriable. Additional information: Access is denied.

Active directory response: 00000005: SecErr: DSID-031521D0, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0

The user has insufficient access rights.

Ez annál is érdekesebb volt, ugyanis eddig az illető csont nélkül tudta kezelni a fiókokat, elvileg nem változott semmi – de attól még jogosultsági problémára hivatkozott a kezelőfelület.

Nem tudott vele mit kezdeni, így hozzám került a dolog, sőt, kapásból egy kérdés is felmerült: amikor az ESM-et (Exchange Management Shell, a PowerShell levelező kiszolgálóra „felkészített” verziója) próbálta más felhasználó nevében futtatni (vész esetére van egy másik, magas jogosultságú fiók), akkor ugyanazt a PS parancsot kiadva, az kiakadt egy hibaüzenettel:

The term ‘Add-ADPermission’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

Kezdjük mindjárt ezzel. Más felhasználóval futtatva az ESM-et egy „sima” PowerShell felületet kapunk, ami nincs felkészítve az Exchange funkciók kezelésére. Bár MS nem támogatja az RBAC kikerülése miatt, de ebbe is be tudjuk tölteni a levelezőkiszolgáló funkcióit:

add-pssnapin Microsoft.Exchange.Management.PowerShell.E2010

Ezután már ugyanúgy használhatjuk az Exchange-specifikus utasításokat, más felhasználó nevében is.

Visszatérve az eredeti problémához. Ahhoz, hogy egy felhasználó az előbb említett jogot tudja módosítani, az „Organization management” csoport tagja kell legyen. De az ugye nem elég, az is szükséges, hogy a csoportnak joga legyen a célfiókhoz – s a kérdéses rendszerben itt csúszott valahol egy porszem a gépezetbe. Mint másik cikkemben is, itt is legegyszerűbben az öröklődés bekapcsolásával lehetett orvosolni a gondot…

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