Home Systems

Teams Status Issues in Outlook — Practical Diagnostic Flow

If Outlook shows the wrong Teams presence, compare Outlook desktop, OWA, and Teams (desktop/web) to isolate device vs account problems. Follow an ordered, non-destructive diagnostic flow with quick fixes, admin checks, and a compact evidence packet to collect before you call support.

11 min read

If Outlook shows the wrong Teams presence, first compare Outlook desktop, Outlook on the web (OWA), and Teams (desktop and web). This quick comparison shows whether the issue is local to a device or tied to the account or tenant. Follow the ordered checks below: start with safe, non-destructive steps, collect logs if needed, then notify your tenant admin or contact Microsoft Support.

What symptom am I actually seeing and where to check first

Answer: Describe the exact mismatch, which client shows the wrong status, which account/mailbox is affected, and whether others see the same. Record this before making changes.

Typical observations:

  • Outlook desktop shows Offline while Teams shows Available.
  • No presence badges appear in Outlook (desktop or OWA).
  • Presence is wrong only for a shared or delegated mailbox.
  • Presence is correct in Teams desktop but wrong in OWA.

Do this quick scope check and record the outcomes:

  1. Open Outlook desktop. Note the presence shown next to your name and a colleague's name.
  1. Open Outlook Web (OWA) in a private/incognito browser session and sign in as the same user; note the presence.
  1. Open Microsoft Teams desktop. Open Teams web in a private/incognito browser session and sign in as the same user; note the presence.

Write the three results as: Outlook desktop / OWA / Teams desktop (for example, Offline / Available / Available).

Use the pattern to decide next steps:

  • If only Outlook desktop is wrong, suspect local Outlook state, add-ins, or cache.
  • If OWA disagrees with Teams web, suspect account-level or tenant configuration problems.
  • If every client is wrong, suspect account or tenant-level issues (tokens, hybrid mailboxes, or tenant policy).

Also note scope: single user, several users, or entire groups. That determines whether you should escalate to an administrator.

Before you start (scope, permissions and safe checks)

Answer: Confirm scope and permissions, and avoid destructive actions until you gather evidence. Collect consent and note mailbox location.

  • You need the affected user's credentials to sign out/sign back in, or an admin to reproduce with that account. Get consent before collecting logs or screenshots.
  • Confirm whether the mailbox is in Exchange Online or on-premises (hybrid). If unknown, record it as evidence.
  • Basic checks should not require admin rights. Admin-only checks are listed later.

What you can do safely:

  • Sign out and back in to Teams and Outlook.
  • Clear Teams cache folders (non-destructive to account data).
  • Disable Outlook add-ins temporarily.

What to avoid until escalation:

  • Deleting or recreating Exchange or AD objects.
  • Changing tenant Conditional Access or hybrid OAuth settings without admin approval.

How Outlook and Teams exchange presence—what components and signals are involved

Answer: Presence depends on Teams publishing status, Outlook requesting presence, tokens from Azure AD, mailbox location, and tenant policies. A failure in any part breaks presence in Outlook.

Presence relies on these parts:

  • Microsoft Teams client: publishes your real-time state.
  • Outlook client: queries presence from Graph or legacy endpoints and caches results.
  • Presence APIs and Microsoft Graph: app consent, Conditional Access, or throttling can block calls.
  • Azure AD / SSO tokens: short-lived tokens power Graph/EWS calls. Token failures stop updates.
  • Exchange mailbox location and hybrid OAuth: cloud mailboxes use Graph/OAuth. On-premises requires hybrid OAuth or correct hybrid config.
  • Tenant policies and federation: presence policies, external access/federation, and app-consent restrictions can block presence sharing.

Typical symptom → layer mapping:

  • Only Outlook desktop affected → local cache or add-in.
  • Web clients disagree or show sign-in errors → token/SSO or tenant policy.
  • Presence missing for on-premises mailboxes → hybrid OAuth misconfiguration.
  • Many users affected tenant-wide → tenant policy, federation, or Graph consent blocking presence.

Step-by-step diagnostic and user fixes (safe, ordered)

Answer: Follow these non-destructive steps in order. Stop when the symptom is fixed, and collect the notes listed later.

  1. Restart in the correct order
  1. Quit Outlook, sign out of Teams and quit Teams. Start Teams, sign in fully, then start Outlook.

Expected result: Outlook picks up the current Teams presence. If fixed, record steps and stop.

  1. Verify in web clients
  1. Open OWA in an incognito/private window and sign in as the same user. Open Teams web in an incognito tab and sign in. Compare presence across Outlook desktop, OWA, Teams desktop and Teams web.

Expected result: Web clients show the authoritative account state. If web clients match each other but not Outlook desktop, continue to client fixes. If web clients disagree, move to account/tenant checks.

  1. Re-authenticate and check system clock
  1. Sign out and back in on both Teams and Outlook to force fresh tokens. Ensure the device clock is set to network time.

Expected result: Fresh tokens clear transient auth errors. If a Conditional Access prompt appears or sign-in fails, note the exact prompt and move to admin checks.

  1. Clear Teams cache (non-destructive)
  1. Close Teams, then clear the Teams desktop cache and restart Teams.
Settings path
Windows: %appdata%\Microsoft\Teams
Mac: ~/Library/Application Support/Microsoft/Teams

Expected result: Teams publishes presence again; Outlook should reflect it. If not fixed, continue.

  1. Soft-repair Outlook and disable add-ins
  1. On Windows, run Office Quick Repair via Settings > Apps > Microsoft Office > Modify (choose Quick Repair first). In Outlook, temporarily disable third-party COM add-ins: File > Options > Add-Ins > Manage COM Add-ins > Go, uncheck non-Microsoft entries, restart Outlook.

Expected result: If an add-in or corrupted cache was the cause, presence returns. If not, continue.

  1. Test on another device or profile
  1. Sign into Outlook and Teams on a different device, or sign into Teams web/OWA with another user's account (with permission). See whether the problem follows the device or the account.

Expected result: If the issue follows the device, it's client-side. If it follows the account, it's an account/tenant issue.

  1. Shared and delegated mailbox checks
  1. If presence is wrong for a shared or delegated mailbox, confirm whether that mailbox is a user mailbox (has its own account) or a true shared mailbox. Presence for shared mailboxes can be inconsistent. As a short-term workaround, use the mailbox owner's presence.

Expected result: If the mailbox is a shared mailbox without an associated user, presence may be absent by design; notify an administrator if you need a different behavior.

  1. When to stop and escalate
  1. If web clients are wrong, sign-in fails, or multiple users in the tenant are affected after these steps, collect the logs listed below and notify your tenant admin or contact Microsoft Support.

Admin checks, what to collect, and when to escalate

Answer: Admins should verify mailbox location, Azure AD sign-ins, Teams policies, and hybrid configuration. Collect the logs below before contacting Microsoft Support.

Admin quick checks:

  • Verify the user's mailbox location (Exchange Online vs on-premises). If on-premises, confirm hybrid OAuth/trust is configured.
  • Check Azure AD sign-in logs for the user's UPN and matching timestamps. Look for Conditional Access or token issuance failures.
  • In Teams Admin Center, verify presence-related policies, external access/federation and app consent settings.
  • Confirm Exchange Online and hybrid configuration: OAuth trusted endpoints and any EWS/Graph access restrictions.

Exact logs and artifacts to collect (attach these to a support ticket):

  • Reproduction path and exact local times (with timezone) when you observed the problem.
  • Screenshots showing the mismatch with timestamps, including Outlook status, Teams status, and OWA if possible.
  • Teams desktop logs: reproduce the issue, then press Ctrl+Alt+Shift+1 in Teams to generate a zip in Downloads. Attach that zip.
  • Outlook client logs: enable Outlook logging (File > Options > Advanced > Enable troubleshooting logging), reproduce the issue, then collect logs from %temp%\Outlook Logging and the user's %localappdata% or %temp% folders. Note the Outlook build number (File > Office Account).
  • Azure AD sign-in log entries for the user covering reproduction timestamps, including Conditional Access evaluation details.
  • Tenant identifiers and account details: tenant ID, affected user UPN(s), mailbox GUID or primary SMTP, mailbox location (on-premises DB name or Exchange Online), and whether MFA or Conditional Access applied.
  • Network trace (optional): a short Fiddler or packet capture during reproduction showing Graph/EWS call failures. Collect this only with appropriate consent and following privacy rules.

Sample support-ticket text to paste and edit:

Support ticket
Problem: Outlook shows incorrect Teams presence for user [user@domain.com].
Observed: Outlook desktop shows "Offline" while Teams desktop and Teams web show "Available".
Time(s): [2026-11-12 09:15:00 America/Los_Angeles].
Reproduction steps: 1) Sign into Outlook desktop and Teams desktop as [user]. 2) Observe presence in Outlook contacts and calendar. 3) Open OWA and Teams web in private browser and observe presence.
Collected artifacts: Teams logs (TeamsLogs.zip), Outlook logs (OutlookLogging.zip), screenshots (Outlook_vs_Teams_timestamped.png), Azure AD sign-in log rows (included), Tenant ID [tenant-id].
Additional notes: Mailbox location [Exchange Online / On-premises DB name]. Conditional Access policies applied: [yes/no].
Request: Please investigate whether presence API calls from Outlook are being blocked or whether hybrid OAuth/trust is missing for this mailbox.

When to notify tenant admin vs contact Microsoft Support:

  • Notify your tenant admin first if multiple users are affected, groups are impacted, or Conditional Access denials appear in sign-in logs.
  • If an admin confirms policies and hybrid settings look correct, open a Microsoft Support incident with the collected packet. Provide Teams logs, Outlook logs, Azure AD sign-ins, and a short network trace if requested.

How to distinguish client-side vs account/tenant-level problems

Answer: Use the client comparison you recorded earlier. The pattern tells you whether the issue is local, account-specific, or tenant-wide.

Decision flow:

  • Only Outlook desktop wrong → client-side (cache, add-in, Outlook build). Fix with restart, cache clear, repair, or profile test.
  • Outlook desktop and Teams desktop wrong but web clients OK → desktop client issues (local Teams or Outlook). Clear caches, reinstall only if other steps fail and the problem does not follow the account.
  • Web clients disagree with each other or both web clients show the wrong presence → account or tenant-level issue (tokens, tenant policy, hybrid mailbox). Check Azure AD sign-ins and tenant settings.
  • Many users affected → tenant policy, federation, or a service-side problem. Notify tenant admin and collect logs.

Verify: how to confirm the fix worked

Answer: Repeat the original scope check and record the same three-client result. Confirm all clients show identical presence.

  1. Close Outlook and Teams.
  1. Sign in to Teams desktop, then start Outlook desktop.
  1. Open OWA and Teams web in private windows.

Expected verified output: All clients show the same presence for the affected account: Outlook desktop / OWA / Teams desktop should be identical (for example, Available / Available / Available).

If the outputs match, the issue is resolved. If they still differ, collect logs and escalate as described.

Short-term workarounds while waiting for an admin fix

Answer: Use these temporary options while admins investigate. They work around UI differences but do not fix the root cause.

  • Use Teams presence as authoritative for meetings and status.
  • Use the mailbox owner's account or calendar instead of a shared mailbox that lacks presence.
  • Encourage affected users to use Teams web or OWA while tenant-level fixes are applied.

These are temporary and should be replaced by an admin configuration fix.

Conclusion

Start with the client comparison: `Outlook desktop / OWA / Teams desktop`. If a restart, cache clear, or sign-in fixes it, stop and record the steps. If web clients disagree or many users are affected, collect the logs listed above and give them to your tenant admin or open a Microsoft Support ticket using the sample text.

Frequently Asked Questions

Why does presence work for some users but not others in the same tenant?

Answer: Per-user differences usually come from mixed mailbox locations, Conditional Access, or app-consent policies. If some mailboxes are on-premises and others in Exchange Online, hybrid OAuth or correct hybrid config is required for presence. Group-targeted Conditional Access or consent rules can also block presence for specific users.

Do I need to reinstall Outlook or Teams to fix presence?

Answer: Usually no. Try the non-destructive steps first: sign out/in, restart in the recommended order, clear Teams cache, run Quick Repair for Office, and disable add-ins. Reinstall or recreate a profile only after you confirm the issue follows the device or persists across devices and you've collected logs.

What if a shared mailbox shows no presence at all?

Answer: Shared mailboxes often don't publish presence like user mailboxes. Check whether the shared mailbox has an associated user account and how delegation is set. Short-term, rely on the mailbox owner's presence or calendar. For a permanent change, ask a tenant admin to convert or assign a user account if appropriate.