Exchange szerver nem küld vagy nem fogad leveleket – lépésről lépésre hibaelhárítás

Exchange szerver nem küld vagy nem fogad leveleket – lépésről lépésre hibaelhárítás

Exchange szerver nem küld vagy nem fogad leveleket – hibaelhárítás teljes lépéslistával

Bevezetés – amikor az Exchange kommunikáció megáll

Az Exchange egy komplex rendszer, amely a DNS-rekordoktól kezdve a transport szolgáltatásokon, adatbázisokon és logokon át működik egységesen. Ha a levelek nem küldhetők el, nem érkeznek meg, vagy a küldés beragad, az általában nem felhasználói hiba, hanem valamilyen infrastruktúra-probléma.

A jó hír: a tipikus okok jelentős része diagnosztizálható már azelőtt, hogy rendszergazdát kellene hívni. Ez a cikk végigvezet a teljes vizsgálati folyamaton, amely segít meghatározni, hogy a hiba a DNS-ben, az Exchange transport rétegében, az adatbázisban vagy a szerver erőforrásainál jelentkezik.

1. lépés – ellenőrizd, futnak-e az Exchange szolgáltatások

Az Exchange működésének alapja, hogy minden kulcsfontosságú szolgáltatás fut. Ha egy szolgáltatás leállt, a levelek nem küldhetők és nem fogadhatók.

Windows Services felületen

  • Nyisd meg: services.msc.
  • Ellenőrizd az alábbiakat:
    • Microsoft Exchange Transport
    • Microsoft Exchange Information Store
    • Microsoft Exchange Active Directory Topology
    • Microsoft Exchange Mail Submission
    • Microsoft Exchange RPC Client Access
  • Ha bármelyik leállt:
    • próbáld meg indítani,
    • ellenőrizd, hogy nincs-e dependency hiba vagy AD-kapcsolati probléma.

2. lépés – a transport queue ellenőrzése

Ha az Exchange nem küldi ki a leveleket, gyakran a transport queue telik meg vagy akad el.

Queue ellenőrzése PowerShellből

Get-Queue

Mit jelentenek az eredmények?

  • Retry – a szerver próbálja újraküldeni a leveleket, de nem sikerül.
  • Poison – sérült üzenetek.
  • Frozen – beragadt levél, amelyet manuálisan kell kezelni.

3. lépés – DNS és MX rekord ellenőrzése

Ha a kimenő levelek nem jutnak el a címzettekhez, a külső DNS- vagy MX-konfiguráció hibás lehet.

Mit kell ellenőrizni?

  • A domain MX rekordja helyes-e.
  • Létezik-e A rekord a mail.domain.hu-hoz.
  • A PTR rekord megvan-e (reverse DNS) – sok szolgáltató ennek hiányában elutasítja az üzenetet.
  • Az SPF rekord tartalmazza-e az Exchange publikus IP címét.

Gyakori DNS-eredetű hibák:

  • 550 Host unknown
  • 554 Relay Access Denied
  • 451 Temporary local problem

4. lépés – adatbázis és mailbox állapot ellenőrzése

Ha a levelek nem érkeznek meg a bejövő postafiókokba, adatbázis-sérülés vagy túlterhelés is lehet az ok.

Mailbox adatbázis ellenőrzése

Get-MailboxDatabase -Status

Tipikus hibaállapotok:

  • Dismounted – az adatbázis nincs csatlakoztatva, nem érhető el.
  • Mounted but Dirty Shutdown – sérülés vagy incomplete commit.
  • Low space on disk – tele a háttértár.

5. lépés – Active Directory kapcsolati hibák

Az Exchange működése erősen AD-függő. Ha nincs kapcsolat az AD-vel, az összes szolgáltatás hibázni kezd.

AD kapcsolat tesztelése

Test-ServiceHealth

Ha hibát jelez, ellenőrizni kell:

  • a DC-k állapotát,
  • a DNS kiszolgálást,
  • a hálózati kapcsolatot.

6. lépés – logok elemzése

Az Exchange részletes naplókat vezet, amelyek segítenek megtalálni a pontos hibaokot.

Hol keresd?

  • Transport log – C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs
  • Event Viewer – Application és System logok
  • Protocol log

7. lépés – tárhely, memória és CPU terhelés vizsgálata

Az Exchange erőforrás-igényes rendszer. Ha a szerver nem kap elegendő memóriát, CPU-időt vagy tárhelyet, a transport szolgáltatás egyszerűen leállhat.

  • 90% feletti diszkhasználat hibákat okozhat.
  • Low memory – a database mountolását blokkolhatja.
  • Magas CPU – a queue feldolgozása lelassul vagy megakad.

8. lépés – mikor kell rendszergazdát hívni?

  • Ha az adatbázist nem lehet mountolni.
  • Ha a transport szerepkör teljesen leállt.
  • Ha DNS-szintű probléma áll fenn.
  • Ha az AD-kapcsolat nem állítható helyre.

Összegzés

Az Exchange e-mail küldési és fogadási hibái összetettnek tűnhetnek, de megfelelő sorrendben haladva gyorsan beazonosítható, hogy a hiba DNS, AD, adatbázis, szolgáltatás vagy queue szinten jelentkezik. Ha a fenti lépéseket követed, már a rendszergazda értesítése előtt feltárhatod a hiba forrását, és gyorsabban elháríthatóvá válik a probléma.

Lépj kapcsolatba velünk

BESZÉLGESSÜNK AZ IT IGÉNYEIDRŐL

Korszerű informatikai megoldásokat biztosítunk vállalkozásoknak.