A support case landed on our desk that, at first glance, seems simple – but actually hides some interesting real-world nuances in Exchange + mobile client interactions:

“A user suddenly has a second calendar in their mailbox.
This new calendar became the default.
All existing meetings are in the old calendar and the user cannot make it the default again.
New events are being created in the new calendar.
This isn’t the first time this has happened.”

Let’s dive into what we found, where Exchange falls short in diagnostics, and how we resolved it.

🔎 Symptoms

Here’s what the user experienced:

• A second calendar folder appeared in the mailbox.
• The new calendar became the default for new events.
• All existing meetings remained in the old calendar.
• Users cannot set the old calendar as default via Outlook UI.
• New meetings/events continued to be saved into the new calendar.
• The issue occurred multiple times with different users.

🧠 Can We Determine Why the New Calendar Was Created?

Unfortunately – no.

Exchange simply does not log who or what client created standard folders like “Calendar”.
Folder metadata does not contain a source identifier (no client tag, no creator info) –  only a creation timestamp is present.

So, we can see when it happened, but not exactly which process triggered it.

📱 The Most Common Root Cause (Practically Verified)

In my experience, the usual culprit in such cases is a third-party mobile or external client application.

Important notes:

• Modern Outlook clients (desktop or mobile official Outlook apps) do not exhibit this behavior in normal operation.
• The majority of confirmed occurrences involve:
  • Third-party mobile applications
  • Corporate container or file manager apps
  • Sync tools with elevated EWS access
  • Antivirus / add-ins on the mail client

So, while Exchange can store and expose folder data, it doesn’t record which client made the change –  this is where client behavior analysis becomes essential.

In this case, the user was actively using an iPhone app called WPXManager. This application is used as regular email client to access Exchange mailbox via Exchange Web Services. It’s user agent is displayed as WorksPad+(ExchangeServicesClient/15.0.913.15) in Exchange connectivity logs (IIS, EWS).

📋 What is recommended

🔁 Step 1. Check Active Mobile Devices

If the issue recurses for one user, temporarily disable all active mobile devices and external clients to see if the problem reoccurs.

Example PowerShell to list devices:

Sometimes there’s a pattern between affected users.

📂 Step 2. Mailbox Folder and Permissions Inspection

Ask for:

And current permissions:

🛠 Step 3. Check Default Calendar with MFCMAPI

To diagnose which calendar is actually default at the MAPI level, we used MFCMAPI.

Key Property to Check

1. Open user mailbox via Session → Logon
2. Navigate to Top of Information Store
3. Select Inbox
4. Find property:

PR_IPM_APPOINTMENT_ENTRYID

This is the identifier of the calendar used by default.

5. Compare that with the PR_ENTRYID values of the old and new calendar folders.

In this case, the PR_IPM_APPOINTMENT_ENTRYID correctly pointed to the new calendar instead of the old one.

🛠 How to fix It

We updated the PR_IPM_APPOINTMENT_ENTRYID property to point back to the old calendar’s PR_ENTRYID:

00000000BDBFA8D47BA0AF42B684FA52D3E9C543010017B76498ADED6B42BDECD0DEC923D96C00000000010C0000

This instantly restored the old calendar as default.

In some cases, you might also need to reset folders with:

Before changing the property, verify that PR_CONTAINER_CLASS for both calendars is correctly set to IPF.Appointment.
If the property is wrong, the folder might not function as a valid calendar.

📌 What We Learned from This Case

• The default calendar setting for new events is stored at a MAPI property level (PR_IPM_APPOINTMENT_ENTRYID).
• Exchange does not log actions that created the calendar — so we cannot definitively blame a specific client without correlating logs.
• However, the likely trigger in this case was the WPXManager app, since it was active on the user’s iPhone and uses corporate services for data access.

🧾 Case Closure Summary

We restored the old calendar as the default by updating the underlying MAPI property.
We cannot prove that WPXManager definitively caused the issue due to lack of logs, but this is the strongest working hypothesis given client activity.
If the issue recurs, the next step is to collect:

1. IIS logs (W3SVC1)
2. EWS logs for the user’s mailbox (Logging/EWS)*

📌 Next Time – Data to Collect

If this happens again:

1. IIS Logs – to see which UserAgents were interacting with EWS at calendar creation time.
2. EWS Logs – to capture the actual client calls that coincide with the timestamp of calendar creation.

This gives you real client-level evidence instead of inference. Unfortunately, appropriate logs were removed already, as customer opened a case too late.

✅ Final Thoughts

This case illustrates a recurring real-world issue:

• Exchange itself doesn’t always reveal the cause
• But with the right tools and steps, you can:
  • identify the actual default calendar
  • fix it at the MAPI level
  • narrow down possible sources

And – as always – third-party mobile clients remain a frequent suspect when unexpected folder operations occur.

End.