none
[E2010] [EWSMA] [VB.NET] - Create Mail Enabled Public Folder - Cannot Read ExtendedProperties RRS feed

  • Question

  • I am trying to port an existing VB6/CDO event-sync application that is installed on the Exchange server, which creates Public Folders and mail-enables them.

    I have gotten pretty far now with EWS API 1.1.  I am able to search, find and Bind to Items and Folders just fine.  However that stuff only gets me half-way to finishing the porting project.  I need to create a Public Folder and have it mail enabled with a specific email address.  For example, my public folder would be named "1234" and the email address for it should be "1234@mycompany.com".

    With the following code, I can easily create the public folder in the location I specify:

                Dim newProjectFolder As New Folder(ews)
                With newProjectFolder
                    .DisplayName = "1234"
                    .Save(PROJECTS_FOLDER_ID)
                End With

    Now if I send an email to "1234@mycompany.com", it is sent back as "Undeliverable" by Exchange, so clearly there is something else I must do (I figured as much).  Now I have read (and re-read) Glen's Exchange Dev Blog (namely: http://gsexdev.blogspot.com/2009/05/mail-enabling-public-folder-with-ews.html).  It appears that the "ExtendedPropertyDefinition" objects hold the key to mail-enabling the folder.  No matter what I try however, I can never return "ANY" extended properties on the just-created folder.  One basic question I had was "after saving, does a folder get a default set of extended property definitions or must I set each one individually?"  This led me to attempt to set various ExtendedPropertyDefinition objects myself both before and after ".Save" but no matter what, the ".ExtendedProperties" collection of my folder always has a Count of zero, as in this example:

    newProjectFolder.ExtendedProperties[0].Value.ToString())        'Results in "Index out of range"


    Since this is a port, I have been able to use Glen's code to successfully obtain the Extended property definitions on "existing" Public Folders created with the VB6-CDO app.  This provides a wealth of information; 28 distinct "DirectoryEntry" properties to be exact. 

    Why does my newly created Public Folder not have any extended properties?  Must I set any/all before/after creating the folder with .Save?

    My Exchange Server is 2010 and I am using VS 2008/VB.Net but can interpret C# code just fine.

    TIA

     


    Tuesday, July 5, 2011 10:00 PM

All replies

  • There is no way in EWS to enumerate extended properties so you need to define each of the properties you want to read (or set) and then use a PropertySet and the Load() method to load them so they would then be available newProjectFolder.ExtendedProperties in your case  or define it in your veiw if your searching. I would suggest you look at the folders your creating in Mapi editor like OutlookSpy of MFCMapi instead this will allow you to see all the properties that are available on your folder and you can see if you can modify etc without needing to write any code.

    The other suggestion i would have is EWS isn't the best method to use to create public folders (its more of a work around where you cant use the EMS) if you can i would strongly advise you look at using the Exchange Management Shell instead http://technet.microsoft.com/en-us/library/bb124411.aspx see new-publicfolder and enable-mailpublicfolder. On 2010 you can make use of Remote powershell which you can call from your .NET code see http://blogs.technet.com/b/exchange/archive/2009/11/02/3408653.aspx


    Cheers
    Glen


    Wednesday, July 6, 2011 2:56 AM
  • Glen,

    Thanks for pointing out OutlookSpy.  I was able to use it to quickly compare the property tags of my existing folders with the new folder I'm creating via EWS.  I have found that there are 4 missing tags, namely PR_CONTAINER_CLASS_W, PR_EXTENDED_FOLDER_FLAGS, PR_PF_PROXY, and PR_PF_PROXY_REQUIRED.  Those last 2 jump out at me, having TRIED to get/set them before on my new folder and having read about them on your blog with regard to mail-enabling.  In fact PR_PF_PROXY is what I am using to get the ExtendedProperties on the existing folders, like so:

    Dim PR_PF_PROXY As ExtendedPropertyDefinition = New ExtendedPropertyDefinition(&H671D, MapiPropertyType.Binary)
    Dim ps As New PropertySet(PR_PF_PROXY)
    ps.BasePropertySet = BasePropertySet.FirstClassProperties
    Dim pf As Folder = Folder.Bind(ews, folderID, ps)

    This always yields results from the folders created via CDO but nothing on my new EWS folder.

    Does the absence of PR_PF_PROXY prevent me from getting/setting any Extended Properties?  Can you please provide a code snippet on creating a public folder and getting/setting extended properties?

    Or let me ask a more fundamental question of you:  Can I use the EWS API to create a public folder in Exchange 2010 and have it mail-enabled?  Or is this whole EWS think just a flaky "work-around" that should not be relied upon?  I've already checked 2 3rd-party .NET components that can do jsut about everyhting in Outlook except what I need to do.  FYI, the whole crux of my mission is to replace our existing mechanism with something that is not intertwined inside Exchange itself.  A remote .NET application would be ideal.  Is EWS the ticket?  Do you really think I  can accomplish the same thing in remote PowerShell with more success?

    Thank you

     

     

    Wednesday, July 6, 2011 8:37 PM
  • The supported method of creating and enabling public folders is to use the Exchange Management Shell as I've already said you can use this remotely in your .NET app and you can be certain that this will work and keep working in the future and would be the method i would recommend.
     
    If your going to try to use EWS (which does work on 2010 last i tested but is a unspported workaroud) you should create the folder first save it then set the extended properties and call update
    ExtendedPropertyDefinition PR_PUBLISH_IN_ADDRESS_BOOK = new ExtendedPropertyDefinition(0x3FE6, MapiPropertyType.Boolean);
    ExtendedPropertyDefinition PR_PF_PROXY_REQUIRED = new ExtendedPropertyDefinition(0x671F, MapiPropertyType.Boolean);
    
    //ENABLE:
    tfTargetFolder.SetExtendedProperty(PR_PUBLISH_IN_ADDRESS_BOOK, MapiPropertyType.Boolean);
    tfTargetFolder.SetExtendedProperty(PR_PF_PROXY_REQUIRED, MapiPropertyType.Boolean);
    
    tfTargetFolder.Update(ConflictResolutionMode.AlwaysOverwrite)

    Cheers
    Glen
    Thursday, July 7, 2011 6:09 AM
  • While I was able to now add a new Extended prop and update another, I still never get the all-important AD proxy object via PR_PF_PROXY.

    After discussing with my supervisor, I now find out that our public folder store on the Exchange 2010 server is actually being replicated from our old, soon to be de-commissioned, E2K3 server.  And since EWS only works with E2K7 and up, I bet that has something to do with it. 

    Thankfully I have (another) alternative route via the Shell.

    Thanks for your responses and your excellent support and contributions to the Exchange developer community!

    Mark

    Thursday, July 7, 2011 5:40 PM
  • I'm late to the party, but I want to echo what BigSancho found. I can set both those extended properties PR_PUBLISH_IN_ADDRESSBOOK and PR_PF_PROXY_REQUIRED to true, but without the PR_PF_PROXY extended property, the public folder I create is never truly mail-enabled.

    In his original article, Glen writes "Once you have set these properties a backgroup process will create the AD Proxy object for this public folder which will contain all the email address's assigned to this and any other folder specific setting such a limits etc." However, that never seems to happen, even after 24 hours.

     

     


    Philadelphia, PA
    Thursday, September 22, 2011 7:16 PM