none
oxfxics and PidTagAccess RRS feed

  • Question

  • Hi,

    With OpenChange, there are folder types which are strictly one-level (Calendar and Address Books, mostly). In online mode, the PidTagAccess property seems to be used and taken into account since the menu action pertaining to folder creation is disabled. Using the fxics protocol, PidTagAccess is requested not to be present during a SynchronizeConfigure request when occurring on the mailbox hierarchy.

    Additionally, when a user creates a subfolder, the server does answer with an "access denied" error code, as specified in the protocol, but Outlook ignores that and keeps requesting the folder creation from time to time.

    Ideally, I would like a work-around for the first problem above, but if not possible, what can I do to avoid the second issue?

    Thanks.

    Monday, September 17, 2012 5:05 PM

Answers

  • Hi Wolfgang,

    We worked on this offline though it appears you must have found an answer or implemented a workaround since you did not respond.  Therefore, resolving this forum thread.

    Regards,

    Mark Miller | Escalation Engineer | Open Protocols Support Team

    Tuesday, December 4, 2012 4:47 PM

All replies

  • Wolfgang,

    One of our engineers will investigate this and follow-up soon.

    Thanks,

    Edgar

    Monday, September 17, 2012 6:59 PM
    Moderator
  • Hello Edgar,

    Any updates regarding Wolfgang's question?

    Thanks,

    Tuesday, September 18, 2012 9:37 PM
  • One additional finding: if I ensure that PidTagAccess is never returned, I can notice using MFCMapi that this property is still assigned with a value 0x63 to all folders. My hypothesis is thus that Outlook, in cached mode, does not care at all for the value returned by the server and considers that all folders owned by the current user are accessible for all the same operations. Is that right?
    Wednesday, September 26, 2012 7:24 PM
  • Hi Wolfgang,

    We worked on this offline though it appears you must have found an answer or implemented a workaround since you did not respond.  Therefore, resolving this forum thread.

    Regards,

    Mark Miller | Escalation Engineer | Open Protocols Support Team

    Tuesday, December 4, 2012 4:47 PM