What does HRESULT 0x80EE0028 (RTC_E_PRESENCE_NOT_ENABLED) mean?

RTC_E_PRESENCE_NOT_ENABLED

Operational meaning: RTC_E_PRESENCE_NOT_ENABLED

This result should be investigated at the point where RTC handles enabling presence, maintaining buddies/watchers/groups, and processing server-roamed presence state, and the condition to prove for this HRESULT is a presence operation was requested before presence was enabled for an appropriate profile.

This result is represented as 0x80EE0028 in the RTC interface facility 0xEE; record the symbolic name alongside the unsigned hexadecimal value; a decimal exception alone is poor evidence for RTC protocol diagnosis.

To establish this result, record enabled profiles, presence profile selection, registration state, and event ordering; this matters because profile enabled for calls does not necessarily mean presence is active.

Signals worth preserving

• Code-specific proof: record enabled profiles, presence profile selection, registration state, and event ordering.
• Correlation key: buddy/watcher URI.
• Protocol or object snapshot: group ID and membership.
• Last completed transition: subscription dialog and expiration.
• Expected output: ACL decision and NOTIFY version.

Protocol and object state

Presence data is subscription state rather than call state; buddy existence, watcher authorization, and current availability are separate concepts. When presence roaming is enabled, the server can act as the presence agent and becomes authoritative for list and subscription updates.

Verification workflow

1. Collect enough evidence to record enabled profiles, presence profile selection, registration state, and event ordering.
2. Test the competing explanation explicitly, because profile enabled for calls does not necessarily mean presence is active.
3. Apply the targeted fix — enable presence through the documented provisioning flow before manipulating subscriptions or lists — and validate both protocol completion and object cleanup.

Do not confuse it with

Recovery and control flow

Recovery should be narrow: enable presence through the documented provisioning flow before manipulating subscriptions or lists; while handling this result, do not let a higher layer simultaneously recreate the same session, registration, listener, or profile.

Example: An application adds a buddy immediately after sign-in but before the presence-enabled event.

Actions that do not address this condition

• Do not expose a private buddy list or watcher identity in general logs.
• Do not overwrite the server list with a stale local snapshot after an uncertain roaming result.

Technical references

• Client Presence Roaming.
• Microsoft RTC return constants.
• SIP presence event package.
• Watcher information.