Outlook nem csatlakozik Microsoft 365-höz 2026: Trying to connect és Disconnected hiba javítása helpdesknek

Frissítve: 2026. augusztus 7.

Az Outlook „Trying to connect" vagy „Disconnected" állapota szinte mindig kliensoldali hiba: a Microsoft 365 tenant elérhető, csak az adott gép Outlook profilja nem tudja lefuttatni a modern authentication (OAuth 2.0) folyamatot, vagy elakad az Autodiscover lekérésénél. A leggyorsabb ellenőrzés: nyisd meg a felhasználó postafiókját outlook.office.com alatt böngészőből. Ha az OWA működik, a probléma 100%-ban a desktop kliensen van, és nincs értelme a Microsoft 365 szolgáltatás állapotát vizsgálni. Ez a runbook végigvezet a helpdesken tipikusan 5–15 perc alatt megoldható javításokon, és megmutatja, mikor kell eszkalálni a tenant adminhoz.

• Ha OWA böngészőből működik, de az Outlook desktop nem, a hiba a kliens oldalon van, nem pedig szolgáltatáskimaradás.
• A „Trying to connect" hibák több mint 70%-a három ok egyikéből fakad: elakadt OAuth token, sérült OST fájl, vagy régi credential a Credential Managerben.
• A %LocalAppData%\Microsoft\OneAuth és IdentityCache mappák törlése, plusz Credential Manager tisztítás, a leggyorsabb univerzális fix.
• Az Autodiscover diagnosztikát Ctrl+jobb klikk, „Test E-mail AutoConfiguration"-nel futtasd. Ha nem autodiscover.outlook.com-ra oldódik fel, DNS vagy on-prem Exchange maradvány rekord a hibás.
• A Microsoft Support and Recovery Assistant (SaRA) most már parancssorból is futtatható, így remote sessionben scriptelhető.
• Ne töröld a PST fájlokat, csak az OST-t. A PST tartalma nem szinkronizálódik vissza szerverről, és tartós adatvesztést okoz.

Miért mutatja az Outlook, hogy „Trying to connect" vagy „Disconnected"?

Amikor az Outlook a jobb alsó sarokban „Trying to connect…" vagy „Disconnected" státuszt mutat, három dolog egyike történik: (1) az OAuth token lejárt vagy sérült, és az újrahitelesítés csendben elbukik, (2) az Autodiscover válaszra vár, ami vagy nem érkezik meg, vagy rossz endpointra irányítja, vagy (3) az OST fájl / profil sérült. A tapasztalatom szerint a helpdesk-ticketek nagyjából 70%-a az első két kategóriába esik, és fél óra alatt zárható. Őszintén, én már százszor futottam ebbe a hibába, és a triage-lista, amit lentebb megosztok, az esetek túlnyomó többségét azonnal beszűkíti.

A pontos gyökér-okok, amelyekkel a napi gyakorlatban találkozom:

• OAuth token cache korrupció. A OneAuth és IdentityCache mappákban levő adatok inkonzisztensek lesznek (leggyakrabban jelszóváltás vagy Conditional Access szabály-módosítás után).
• Elavult vagy duplikált Credential Manager bejegyzés. A Windows még őrzi a régi jelszót vagy az előző e-mail címet a MicrosoftOffice16 vagy ADAL névtér alatt.
• Sérült OST fájl. A lokális offline cache (általában 20–50 GB-os) fájlrendszer-hiba, hirtelen áramszünet vagy tele SSD miatt inkonzisztens állapotba kerül.
• Autodiscover redirect. A kliens egy régi on-premises Exchange szervert talál (pl. autodiscover.cegnev.hu), amely már nem szolgálja ki a postafiókot.
• Modern Authentication letiltva. Ritka, de előfordul régi image-eken; a Basic Auth Exchange Online-ban 2022 októbere óta végleg letiltva van.
• Hálózati akadály. Proxy, VPN split-tunnel konfiguráció vagy blokkolt 443-as port.
• Sérült Outlook telepítés. Click-to-Run frissítés félbeszakadt; ilyenkor Quick Repair vagy Online Repair szükséges.
• MFA kényszerítés utáni token hiba. Microsoft Entra ID Conditional Access szabály életbe lépett, és a régi refresh token invalidálódott. Ha ilyen mintát látsz több felhasználónál egyszerre, olvasd el a Microsoft 365 MFA kizárás hibaelhárítási útmutatót, mert közös gyökér-ok.

5 perces triage checklist a helpdesknek

Mielőtt bármit is elkezdenél tekergetni, futtasd le ezt az öt lépést telefonon vagy remote sessionben. Ez a triage az esetek nagyjából 40%-át megoldja, és a maradék 60%-nál is szűkíti a gyanúsítottak körét. Nálam ez a checklist minden Outlook-jegynél az első lépés, szinte reflexből.

1. OWA-teszt. Nyisd meg https://outlook.office.com-t a felhasználó gépén, jelentkezzen be. Ha a levelezés jön, a tenant és a fiók rendben van, tehát a hiba a desktop Outlookon.
2. Send/Receive kényszerítése. Nyomj F9-et. Ha a státusz „Trying to connect" marad több mint 60 másodpercig, van hiba. Ha csatlakozik, valószínűleg csak metered network vagy battery saver szüneteltette a szinkronizálást.
3. Autodiscover teszt. Tartsd nyomva a Ctrl-t, és jobb klikkeld a tálcán az Outlook ikont, majd „Test E-mail AutoConfiguration". Vedd le a „Use Guessmart" és „Secure Guessmart Authentication" pipákat, és futtasd. A Results tabon https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml-nek kell szerepelnie.
4. Csökkentett módú indítás. Win+R → outlook.exe /safe. Ha csökkentett módban csatlakozik, egy add-in okozza a problémát (leggyakoribbak: régi Salesforce, Adobe, McAfee, Cisco Webex).
5. Kapcsolat státusz megnyitása. Tartsd nyomva a Ctrl-t, és jobb klikkeld az Outlook tálca ikont, majd „Connection Status". Nézd meg, hogy az Exchange endpoint sora „Connected" vagy „Disconnected", és melyik protokollt használja (MAPI/HTTP kell, hogy legyen).

Hitelesítési cache tisztítása: OneAuth, IdentityCache, Credential Manager

Ha a triage nem oldotta meg, a következő lépés a modern authentication token cache teljes eldobása. Az elmúlt évben ez lett az egyszerűen leggyakoribb fix Windows 11-en, mert a Microsoft áttért az egységes OneAuth stackre. És ez a stack szeret elakadni, amikor a felhasználó jelszót vált vagy egy Conditional Access szabály életbe lép.

1. Outlook és minden Office-alkalmazás bezárása

Task Managerben ellenőrizd, hogy az OUTLOOK.EXE, MSTEAMS.EXE, OneDrive.exe, lync.exe és WINWORD.EXE ne fusson. A OneAuth mappa fájljait ezek az appok mindegyike lockolja.

2. OneAuth és IdentityCache törlése

Nyisd meg a Fájlkezelőt, és menj be ide:

%LocalAppData%\Microsoft\OneAuth
%LocalAppData%\Microsoft\IdentityCache

Mindkét mappa tartalmát töröld ki (magukat a mappákat hagyd meg). Ha nem tudod törölni, még mindig fut valamelyik Office process, nézd meg újra a Task Managert.

3. Credential Manager tisztítása

Nyisd meg a Vezérlőpult → Hitelesítőadat-kezelő → Windows-hitelesítőadatok panelt, és töröld az összes bejegyzést, amelynek a neve tartalmazza a következőket:

• MicrosoftOffice16_Data:*
• MicrosoftAccount:*
• OneDrive Cached Credential
• msteams_*
• Bármi, ami az Outlook Anywhere endpointra utal (outlook.office365.com).

Ugyanez parancssorból, admin PowerShellben (hasznos, ha script kell hozzá tömeges javításhoz):

cmdkey /list | ForEach-Object {
    if ($_ -match "Target: (MicrosoftOffice16_Data.*|MicrosoftAccount.*)") {
        $target = $matches[1]
        Write-Host "Removing: $target"
        cmdkey /delete:$target | Out-Null
    }
}

4. Outlook újraindítása és bejelentkezés

Indítsd el az Outlookot. Egy „Sign in to Microsoft" ablak fog megjelenni; jelentkeztesd be a felhasználót a teljes UPN-nel (nem az e-mail alias-szal). Az esetek 60–70%-ában ez feloldja a problémát 30 másodpercen belül. Nekem múlt héten ez oldott meg egy három napja húzódó ticketet, ahol előtte már két másik kolléga is próbálkozott profil-újraépítéssel.

Outlook profil javítása és az OST fájl újraépítése

Ha a cache tisztítás után is „Trying to connect" marad, a következő gyanúsított a sérült OST fájl vagy a rossz profil. Az OST (Offline Storage Table) egy lokális cache a szerveren tárolt postafiókról; Exchange Online esetén 50 GB-ig nőhet, és bőven talál módot arra, hogy inkonzisztens legyen.

Első lépés: Repair the account (kevésbé invazív)

Outlook → Fájl → Fiókbeállítások → Fiókbeállítások → E-mail tab, itt válaszd ki a fiókot, majd Repair. A wizard újra lefuttatja az Autodiscovert, frissíti az OAuth tokent, és újraírja a profilban a szerver endpointokat. Ez sok esetben elég, és nem kell újratölteni a teljes OST-t.

Második lépés: OST fájl átnevezése

Ha a Repair nem segít, az OST-t kell újraépíteni. Zárd be az Outlookot, majd navigálj ide:

%LocalAppData%\Microsoft\Outlook

Keresd meg a felhasználó .ost fájlját (általában [email protected]), és nevezd át .ost.old-re. Nyisd meg az Outlookot; létre fog hozni egy új OST-t, és elkezdi letölteni a postafiók tartalmát a szerverről.

Harmadik lépés: Új Outlook profil létrehozása

Ha az OST újraépítés sem oldja meg, hozz létre egy teljesen új profilt:

1. Vezérlőpult → Mail (Microsoft Outlook) → Show Profiles.
2. Kattints az „Add…" gombra, és adj neki egy új nevet (pl. Outlook2026).
3. Add hozzá a felhasználó M365 fiókját.
4. Állítsd be „Always use this profile" opciót az új profilra.
5. Indítsd el az Outlookot.

Ha az új profil hibátlanul csatlakozik, a régit később törölheted. Ez azért működik, mert a profil néha korrupt regisztrációs kulcsokat tartalmaz a HKCU\Software\Microsoft\Office\16.0\Outlook\Profiles alatt, amelyeket „takarítani" nem érdemes.

Autodiscover diagnosztika: Test E-mail AutoConfiguration és Remote Connectivity Analyzer

Az Autodiscover az a szolgáltatás, ami megmondja az Outlooknak, hol találja a postafiókot. Ha ez rossz endpointra irányít, az Outlook „Disconnected"-ben ragad. Ez különösen gyakori olyan környezetekben, ahol korábban on-premises Exchange volt, és a DNS zóna maradványokat tartalmaz.

Lokális teszt: Test E-mail AutoConfiguration

Tartsd nyomva a Ctrl-t, és jobb klikkeld a tálcán az Outlook ikont, majd „Test E-mail AutoConfiguration". Vedd le a „Use Guessmart" és „Secure Guessmart Authentication" pipákat, hagyd bepipálva az „Use AutoDiscover" opciót, add meg a felhasználó e-mail címét és jelszavát, majd kattints Testre.

A Results tabon a következőket kell látnod:

<Server>[email protected]</Server>
<Protocol>
    <Type>EXHTTP</Type>
    <Server>outlook.office365.com</Server>
    <SSL>On</SSL>
    <AuthPackage>Anonymous</AuthPackage>
</Protocol>

Ha ehelyett egy on-premises Exchange szerver nevét látod (pl. ex01.ceg.local), vagy egy régi autodiscover.ceg.hu CNAME-re próbál felállni, akkor DNS oldali probléma van. Menj a Log tabra, és nézd meg, milyen URL-eket próbál az Autodiscover, általában a következő sorrendben:

1. https://ceg.hu/autodiscover/autodiscover.xml (root domain; ez a legkockázatosabb, gyakran generic 200-at ad!)
2. https://autodiscover.ceg.hu/autodiscover/autodiscover.xml
3. SCP lookup (Active Directory-ból)
4. SRV record: _autodiscover._tcp.ceg.hu
5. HTTP redirect a Microsoft 365 autodiscover-s.outlook.com-ra.

Távoli teszt: Microsoft Remote Connectivity Analyzer

Ha bizonytalan vagy, hogy a probléma DNS-e vagy klienskonfigurációs, futtasd le a Microsoft Remote Connectivity Analyzer-t (testconnectivity.microsoft.com). Válaszd az „Outlook Autodiscover" tesztet, add meg a felhasználó UPN-jét és jelszavát (vagy modern auth tokent), és nézd meg, milyen endpointra oldódik fel. Ha innen működik, de a kliens gépről nem, akkor lokális DNS vagy proxy hibáról van szó. Flush-old a DNS-t ipconfig /flushdns-el, majd teszteld újra.

Support and Recovery Assistant (SaRA), automatizált fix

A Microsoft Support and Recovery Assistant egy külön letölthető eszköz, ami automatikusan futtat egy sor diagnosztikát és javítást. Az elmúlt években a helpdesk egyik legjobb barátjává vált, mert egy csomó rutin ellenőrzést egyetlen scriptbe zár. Én személy szerint minden helpdeskes gépre alap-telepítem, mert a júniori kollégák így legalább egy próbálkozásra elindulnak, mielőtt eszkalálnának.

Interaktív telepítés (végfelhasználó gépén)

Töltsd le a SaRAsetup.exe-t a aka.ms/SaRA címről, futtasd, és válaszd az „Outlook" → „Outlook keeps asking for my password / won't connect" opciót. A SaRA lefut, körülbelül 3–10 perc alatt, és a végén jelentést ad.

Silent futtatás parancssorból (helpdesk / RMM)

Ha RMM-en vagy Intune Proactive Remediation scriptben szeretnéd futtatni, ezt használd:

SaRAcmd.exe -S OfficeScrubScenario -AcceptEula -CloseOffice
SaRAcmd.exe -S OutlookScenario -AcceptEula

Az első parancs csak akkor kell, ha az Office telepítést kell tisztítani (radikális, csak végső eset). A második az általános Outlook diagnosztika.

Hálózati problémák: VPN, proxy, 443-as port és Optimized routing

Ha az összes kliensoldali javítás után is „Disconnected" marad, és a probléma több felhasználót érint egyszerre, hálózati oldalon keresd. Az Exchange Online hivatalos endpoint listája minden IP-t és FQDN-t felsorol, amit ki kell engedni a proxy vagy tűzfal szinten.

VPN split-tunnel

Home office korban ez a leggyakoribb hibaforrás. Ha a teljes M365 forgalom a vállalati VPN-en megy át, egyrészt lassú, másrészt a proxy vagy SSL inspection kibontja és újracsomagolja a forgalmat. És az Outlook modern authenticationjével nem barátkozik jól. A Microsoft ajánlása: az „Optimize" kategóriájú végpontokat (Exchange Online, SharePoint Online, Teams media) split-tunnellel közvetlenül az internetre engedd, és csak az „Allow" és „Default" kategóriákat routold VPN-en. Ha a felhasználó gépe VPN-en van, próbáld leválasztani a VPN-t és futtasd le a triage-t. Ha VPN nélkül működik, a probléma a VPN konfigurációban van. A Windows VPN csatlakozási hibák hibaelhárítási cikkünk részletesen tárgyalja a split-tunnel beállítást.

443-as port és SSL inspection

Ha a tűzfal blokkolja a 443-as portot valamelyik *.outlook.com vagy *.office365.com hostra, az Outlook nem csatlakozik. Teszt PowerShellből:

Test-NetConnection outlook.office365.com -Port 443
Test-NetConnection autodiscover-s.outlook.com -Port 443
Test-NetConnection login.microsoftonline.com -Port 443

Ha bármelyik „TcpTestSucceeded : False"-t ad, tűzfal vagy proxy blokkolja a forgalmat. Az SSL inspection szintén problémás lehet: a Microsoft explicit kéri, hogy az Exchange Online forgalmat NE bontsd ki és inspektáld, mert a modern authentication cert-pinninget használ.

Proxy kizárás

Ellenőrizd a rendszer proxy beállítást és a WinHTTP proxyt:

netsh winhttp show proxy

Ha van egy régi belső proxy, ami már nem létezik, reset-eld:

netsh winhttp reset proxy

Fejlett hibaelhárítás: ExcludeHttpsRootDomain regisztrációs kulcs

Ez a fix akkor kell, ha az Autodiscover Log tabon látod, hogy a kliens a root domainen (pl. https://ceg.hu/autodiscover/autodiscover.xml) egy sikeres, de HAMIS választ kap. Általában azért, mert egy WordPress vagy más webalkalmazás minden 404-et generic 200-zal válaszol meg. Ilyenkor az Outlook megpróbálja értelmezni a HTML választ Autodiscover XML-ként, és beleragad. Én egyszer egy egész délutánt eltöltöttem ezzel a hibával egy tenant migráció után, mielőtt rájöttem, hogy a marketing csapat WordPress-oldala okozza.

A javítás egy DWORD regisztrációs kulcs:

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Outlook\AutoDiscover
Név:      ExcludeHttpsRootDomain
Típus:    REG_DWORD
Érték:    1

PowerShell scriptben, tömeges deploymenthez:

$path = "HKCU:\SOFTWARE\Microsoft\Office\16.0\Outlook\AutoDiscover"
if (-not (Test-Path $path)) { New-Item -Path $path -Force | Out-Null }
Set-ItemProperty -Path $path -Name "ExcludeHttpsRootDomain" -Value 1 -Type DWord
Write-Host "ExcludeHttpsRootDomain beállítva."

Kiegészítő kulcsok, amiket együtt szoktam alkalmazni tenant migráció után maradvány DNS-sel:

• ExcludeHttpsAutoDiscoverDomain = 1, kihagyja az autodiscover.ceg.hu-t is
• ExcludeScpLookup = 1, kihagyja az Active Directory SCP lookupot (hybrid környezetben óvatosan!)
• ExcludeSrvRecord = 1, kihagyja az SRV rekord lookupot

Ticketing checklist: mit dokumentálj a jegyben

A jó ticket dokumentáció megspórolja a következő eszkalálásnál a duplikált munkát. Amikor Outlook „Disconnected" hibát zársz, az alábbi információkat mindig írd be a jegybe. Érdemes rákényszeríteni a helpdesk sablonjaid ezt is:

1. Környezet: OS verzió (winver), Office build (Fájl → Fiók → About Outlook), tenant név, cache mode (Cached vs Online).
2. Triázs eredmény: OWA működik-e? Send/Receive kényszerítés eredménye? Autodiscover teszt endpointja?
3. Alkalmazott javítások sorrendben, mit próbáltál, mi működött, mi nem.
4. Aki érintett: egy felhasználó vagy több? Mikor kezdődött? Egybeesik-e valami tenant változással (jelszó reset, Conditional Access szabály, MFA rollout)?
5. Hálózat: irodából, home office-ból, VPN-en, hotspotról?
6. Screenshot a Connection Status ablakról és a Test E-mail AutoConfiguration Results tabjáról.

Ha ezt a hat pontot megvan minden jegyen, a második szintű támogatás vagy a Microsoft Support-nak eskaláció is 10 percen belül megkapja a szükséges kontextust. Így nem küld vissza „please provide the following diagnostics" válasszal.

Gyakran ismételt kérdések

Miért ragad az Outlookom „Trying to connect" állapotban, ha az internet működik?

Az internet-kapcsolat és az Outlook–Exchange kapcsolat két külön dolog. A leggyakoribb ok egy lejárt OAuth token vagy egy rossz Credential Manager bejegyzés. Ilyenkor a Windows látja az internetet, de az Outlook nem tud modern authenticationnel bejelentkezni. Az elsőként kipróbálandó fix: bezárni minden Office appot, törölni a %LocalAppData%\Microsoft\OneAuth és IdentityCache mappák tartalmát, valamint a Credential Managerből az MicrosoftOffice16_Data bejegyzéseket, majd újranyitni az Outlookot.

Elveszíthetek levelet, ha törlöm az OST fájlt?

Nem, ha csak M365 vagy Exchange Online postafiókod van, mert az OST csak egy lokális cache. Minden levél a szerveren van, és a szinkronizálás újra letölti őket. DE: ha van PST fájlod (nem-szinkronizált archív mappák), azt SOSE töröld. Az OST fájlt átnevezéssel biztonságosabb kezelni (.ost → .ost.old), mert ha valami mégis félremegy, visszaállítható.

Hogyan tesztelhetem az Autodiscovert Outlookban?

Tartsd nyomva a Ctrl billentyűt, és jobb klikkeld a tálcán az Outlook ikont, majd válaszd a „Test E-mail AutoConfiguration" opciót. Add meg az e-mail címet és jelszót, vedd le a „Use Guessmart" pipákat, hagyd bepipálva az „Use AutoDiscover" opciót, majd kattints Testre. A Results tab megmutatja, milyen endpointra oldódott fel; Microsoft 365-nél outlook.office365.com-nak kell lennie.

Mit csinál a Support and Recovery Assistant (SaRA), és biztonságos-e futtatni?

A SaRA a Microsoft hivatalos diagnosztikai eszköze, ami automatikusan lefuttatja a leggyakoribb Office és Outlook javításokat: Autodiscover teszt, profil check, credential reset, add-in ellenőrzés. Biztonságos futtatni végfelhasználói gépen, mert csak olvas és rutin javításokat végez, nem törli a leveleket. Az egyetlen szcenárió, aminél óvatos kell lenni, az „Office Scrub" mód, ami teljesen eltávolítja az Office telepítést; ezt csak akkor futtasd, ha újratelepítést tervezel.

Miért mutat az Outlook „Disconnected" jelet VPN-en?

A vállalati VPN-ek gyakran routolnak minden M365 forgalmat a központi proxy-n keresztül, ami SSL inspection-t vagy egyéb forgalom-vizsgálatot végez, és a modern authentication cert-pinning miatt ez elakad. A Microsoft ajánlása a split-tunnel: az Exchange Online, SharePoint és Teams forgalmat közvetlenül az internetre engedd, ne VPN-en át. Gyors teszt: kapcsold ki a VPN-t, és nézd meg, csatlakozik-e az Outlook. Ha igen, a VPN a hibás.

Mikor kell új Outlook profilt létrehozni a régi javítása helyett?

Új profilt akkor érdemes létrehozni, ha a Fiókbeállítások → Repair, az OST újraépítés és a hitelesítési cache tisztítás sem oldotta meg a problémát, vagyis harmadik-negyedik lépésként a hibaelhárításban. Az új profil takarít minden korrupt regisztrációs kulcsot a HKCU\Software\Microsoft\Office\16.0\Outlook\Profiles alatt, amit egyébként manuálisan nem érdemes bántani. A régi profilt először hagyd meg, és csak akkor töröld, amikor legalább egy hétig stabilan működik az új.