none
[EWS][C#] Tell if two accounts see the same public folder hierarchy? RRS feed

  • Question

  • Hello,

    Please correct me if I'm wrong, but my understanding is that every Exchange server within an organization (or forest) will see the same public folder tree hierarchy assuming that hierarchy replication is working correctly and is up to date.  However, if hierarchy replication is not working (or hasn't finished replicating a recent change) then it’s possible I might see a slightly different public folder hierarchy depending on which EWS CAS server my application is talking to.  Correct?

    I'm working on a C# EWS application that needs to work with multiple email accounts that may be located in different Exchange organizations (in other words located in different Active Directory forests) that does processing on public folders.  I was wondering what would be the best / most efficient way to determine if two email accounts are seeing the same public folder hierarchy (without needing to traverse the entire hierarchy and also assuming hierarchy replication is working correctly and is up to date)?  I would like to skip doing redundant processing on the same public folder hierarchy, if I get more than one email account in the same Exchange organization.  I believe asking if two email accounts are located in the same exchange organization would give the same answer, correct? How could I determine that using EWS only?

    I tried comparing the FolderIds of the DistinguishedFolderIdNameType.publicfoldersroot (obtained using a EWS GetFolder call) but discovered that I get back different IDs if the two email accounts are accessing different public folder mailbox databases within the same forest.  I'd prefer a solution that only needs to use EWS and would work with either Exchange 2007 SP1 or greater or Exchange 2010 or greater.

    Thanks,
    Greg

    Thursday, February 10, 2011 8:58 PM

All replies

  • If your using Public Folders (and this is no longer a requirement in Exchange) then a Mailbox database will have a associated public Folder Store configured. The folder hierarchy is replicated between all Public FolderStore the store that you access when you access a mailbox via any Exchagne API including EWS is the public store that is associated with the MailboxStore the mailbox is located in it has nothing to do with which CAS you choose to use. When new public folders get created there will be a replication delay. Generally all the Id's used in Exchange need to be unique you could try PR_Search_Key i would suggest you use an MAPI editor like mfcMapi or OutlookSpy to look at the properties available the another idea would be to use the FQDN of the CAS URL to work it out.

    Cheers
    Glen

    Friday, February 11, 2011 1:21 AM
  • Thanks for the clarification about how a public store is associated with a mailbox store.  FWIW, I found that setting in the Exchange Managment Console, in Exchange 2010, in "Microsoft Exchange -> Microsoft Exchange On-Premises (...) -> Organiziation Configuration -> Mailbox -> Database Managment tab", select and right click on a mailbox database, goto the Client Settings tab, there you can choose which public folder store to assoicate with that given mailbox store.

    Thanks for the suggestions; I'll look into trying the PR_Search_Key.  Maybe I could get the PR_Search_Key through EWS via an extended property?

    I'm unsure about using the FQDN of the CAS URL -- wouldn't I get a different FQDN for each CAS URL within the Exchange organiziation?  I was thinking maybe I coud use the SMTP domain off of the account's email address?  But I wasn't sure if the primary SMTP email addresses could have different SMTP domains within the same Exchange organiziation.

    Thanks,
    Greg

    Friday, February 11, 2011 2:46 PM
  • The Domain part of the FQDN for the CAS servers should be the same while the primary email address domain could be different when orgs have multiple SMTP domains. You need to use Extended Mapi properties if you want to use the PR_Search_key you can use a mapi editor to work out the property definition and whether its worth while to use.

    Cheers
    Glen

    Saturday, February 12, 2011 12:37 AM