That’s My Name, Don’t Wear It Out

Part 1

It used to be in earlier versions of Exchange, you were able to change the names of the “special” folders, like Inbox, Calendar, Tasks, etc. This is because MAPI keeps track of the Entry ID for these special folders in properties stored on the root folder. As long as the folder never got deleted, the Entry ID for that folder would work, and if it ever did, we simply updated the Entry ID we had stored.

It was always risky to do that though, because if you were using a path or URL that was defined by the display name of the folder, you could break yourself. So we locked down certain APIs, such as OOM (https://support.microsoft.com/kb/831363) to not allow you to update the display name on some special folders. EWS and OWA had the same limitation in Exchange 2007 (and continue to in Exchange 2010). As you are probably aware, EWS and OWA use an internal API dubbed “XSO” for communicating with the information store. What’s new in Exchange 2010 is that we moved MAPI to the middle tier, into a process we call RPC Client Access. So now, Outlook, CDO 1.21, and all other MAPI applications talk to the CAS server instead of talking to the mailbox role directly.All the MAPI logic gets funneled through XSO as it goes to the store. Because we’re going through XSO now, we are subject to the same constraints that EWS and OWA endure. This means that MAPI can now no longer update the PidTagDisplayName property on special folder types.

For a list of folder types that cannot be renamed, run this PowerShell command in EMS: [System.Enum]::GetNames([Microsoft.Exchange.Data.Storage.DefaultFolderType])

This is obviously just an enumeration that includes members such as “None”, so use your common sense to decipher this list, but you should get the idea of which folders these enumeration values are referring to.

We saw this new truth surface recently with a customer who was attempting a CopyTo operation on a message store object in MAPI. As MAPI went through each folder attempting to SetProps on the destination, the call failed with MAPI_E_CORRUPT_DATA which bubbled up to the caller. Digging in, we saw that the problem was in setting the PidTagDisplayName on the Common Views folder. We were able to verify that in Exchange 2007, EWS is unable to change the DisplayName on the special folders but MAPI is able to, however in Exchange 2010, this same operation doesn’t work from MAPI.

So if your MAPI application is doing any copy operations or calling SetProps on a folder object, you may want to exclude PidTagDisplayName property on these special folders.

Part B

This also serves as a good recommendation in general for testing your MAPI applications against Exchange 2010. If something gives you an error that didn’t used to on previous versions (especially Exchange 2007) then chances are, the problem is related to RPC Client Access (RCA) and MAPI going through XSO. To see if your problem is related to MAPI or is in XSO, try doing the same operation (or as close as you can) in EWS. You can use EWSEditor to run through your repro. If you get a similar error, it’s most likely the case that what you are seeing is a result of MAPI going through the XSO layer. If EWS and/or OWA don’t have the same problem as your application does, your problem becomes a little more interesting.