A while ago Steve posted information about how to turn of various types of “crawling” in Outlook via named properties that can be set on a store to tell Outlook whether or not it is okay to “crawl” the store in different scenarios.  There are cases where you might have tons of folders in a store and you don’t want Outlook to enumerate all these folders because it would impact performance.  I was recently asked if these properties could be set via a simple VB script.  Turns out it is pretty straight forward to set this property via the PropertyAccessor in Outlook’s object model.

The following script will work with Outlook 2007 and greater.  It is simply a sample script which can be used to set the CrawlSourceSupportMask to enable or disable Outlook crawling a store to look for Contact, Task, and Calendar folders in an opened store.  You could easily modify this script to set ArchiveSourceSupportMask if you needed to – this disables/enables Outlook crawling open stores looking for folders that need to be archived.

Option Explicit
Main()
Sub Main
    On Error Resume Next
    Dim oApplication 'As Outlook.Application
    Set oApplication = CreateObject("Outlook.Application")
    If Err.number <> 0 Then
        DisplayError "Unable to get Outlook application object, " & _
                     "make sure Outlook 2007 is installed on this computer."
        Exit Sub
    End If
    Dim oSession 'As Outlook.Namespace
    Set oSession = oApplication.Session
    If Err.number <> 0 Then
        DisplayError "Unable to get current Outlook session, make sure " & _
                     "Outlook 2007 is running."
        Exit Sub
    End If
    
    MsgBox "Choose an Outlook message store to configure.", _
                1, _
                "Configure Outlook Do Not Crawl"
    
    Dim oFolder 'As Outlook.Folder
    Set oFolder = oSession.PickFolder
    If oFolder Is Nothing Then
        Exit Sub
    End If
    If Err.number <> 0 Then
        DisplayError "Unable to get Folder."
        Exit Sub
    End If
    Dim oStore 'As Outlook.Store
    Set oStore = oFolder.Store
    
    If Err.number <> 0 Then
        DisplayError "Unable to get Store."
        Exit Sub
    End If
    
    Dim choice
    choice = MsgBox ("Do you want Outlook to crawl the message store you selected?", _
                4, _
                "Configure Outlook Do Not Crawl")
    Dim CrawlSourceSupportMask
    CrawlSourceSupportMask = "http://schemas.microsoft.com/mapi/string/" & _
       "{00062008-0000-0000-C000-000000000046}/CrawlSourceSupportMask"
    Dim propValue
    propValue = oStore.PropertyAccessor.GetProperty(CrawlSourceSupportMask)
    If Err.number = -2147221233 Then
        MsgBox "CrawlSourceSupportMask is not currently set, click OK to create it and set it."
        Err.Clear
    ElseIf Err.number <> 0 Then
        DisplayError "Unable to get CrawlSourceSupportMask property."
        Exit Sub
    End If
    
    If choice = 6 Then
        oStore.PropertyAccessor.SetProperty CrawlSourceSupportMask, CLNG(1)
    ElseIf choice = 7 Then
        oStore.PropertyAccessor.SetProperty CrawlSourceSupportMask, CLNG(0)    
    End If
    
    If Err.number <> 0 Then
        DisplayError "Failed to set CrawlSourceSupportMask."
        Exit Sub
    End If
    If choice = 6 Then
        MsgBox "Success!  Do Not Crawl has been enabled on this store."
    ElseIf choice = 7 Then
        MsgBox "Success!  Do Not Crawl has been disabled on this store."
    End If
    
End Sub
Sub DisplayError(strMessage)
    MsgBox strMessage & vbCrlf & vbCrlf & _
           "Error Information" & vbCrlf & _
           "Number: " & Err.number & vbCrlf & _
           "Description: " & Err.Description, ,"Error!"
End Sub

Fellow developer support engineer, Patrick Creehan, has any interesting post about the delta between the documentation of DeleteItem calls and the actual behavior involving including the ChangeKey in the ItemId of the item you want to delete.  In theory the ChangeKey would be required for DeleteItem requests to ensure that you know you have evaluated the latest version of the item and decided to delete it.  If you pass an ItemId with a stale ChangeKey, you should get a error indicating this isn’t the latest version of the item and you can retrieve it to make sure you still want to delete it.  This is how an UpdateItem request works.  As Patrick’s post indicates, DeleteItem doesn’t work the same way UpdateItem works – it just ignores the ChangeKey and does the delete no matter what.  Patrick has a workaround to provide similar functionality in case you need it.

…

The Exchange API team announced, they’ve posted a beta SDK for Exchange 2010 on MSDN.  In their post they highlight the most notable change in the structure of this SDK:

“…For earlier product releases, all Exchange developer documentation is included in a single SDK. For Exchange 2010, documentation for each technology area is published in a separate SDK, making it quicker and easier for you to find information that you need. The following SDKs are available online for Exchange 2010 Beta:

• Exchange 2010 Beta Web Services SDK June 2009
• Exchange 2010 Beta Transport Agents SDK June 2009
• Exchange 2010 Beta Backup and Restore SDK June 2009…”

…

Henning Krause posted a couple interesting articles that go along with my earlier, performance themed EWS posts (part 1 & part 2).  His first post is about processing items in a folder using the EWS Managed API, he walks through some of missteps I see customer make when they complain about how “slow” EWS is – as he points out it often comes down to choosing the right tool for the job and synchronization is often over looked by novice EWS developers who choose to loop through an entire folder looking for changes instead.  His second post is more about limiting the requested PropertySet to increase the performance of your EWS code – something I have pointed out earlier with GetItem and FindItem calls but it is good to reinforce this concept in SyncFolderItem calls as well. 

Speaking of GetItem vs. FindItem calls – Henning has a third post which shows you how to get the message body with a FindItem request even though technically you can’t request the “item:body” schema property in a FindItem’s PropertySet.  His post points out an important concept which is that schema properties (or “first class properties” as they are sometimes called) are tied back to extended properties which are the “raw values”.  Often times certain limitations are applied to the schema properties because they calculations can be expensive or unavailable at a certain time – however in some cases you can get around this by using and understanding the correlating extended properties.

…

Jason Nelson posted a couple items (round 1 and round 2) on the Exchange team blog about named property mapping detailng the history and problems with this mapping and upcoming changes in Exchange 2007 SP2 and Exchange 2010.  Most notable from the “round 2” post is that in Exchange 2007 SP2 and Exchange 2010 “…no x-headers are ever promoted to individual properties if a client has not already requested (and mapped) them. Not even authenticated submissions can create new named property mappings.”  This could pose a problem if your application relies on these headers to do processing, if you are using an Exchange API with property access like EWS, MAPI, CDO 1.21, WebDAV, or Outlook 2007+ object model then fear not, “…x-headers are still stored in PR_TRANSPORT_HEADERS and still accessible to MAPI clients but they are not individual properties.”

However, if your application uses IMAP the story is different…

“Exchange2007 does not contain an STM file - it doesn't save the original mime content. Messages are converted to MAPI. IMAP has the ability to search based on header values, but if these are not promoted, the result is that the message is not contained in the results. If a client has previously mapped t he header in question (a MAPI client) then messages delivered after this will have the x-header promoted as an individual property.”