Akash Blogging...... https://docs.microsoft.com/archive/blogs/akashb/feed.xml Tue, 14 Nov 2017 21:09:51 GMT en-US hourly 1 EWS Script to automatically generate registry keys to enable Custom Forms in Outlook https://docs.microsoft.com/archive/blogs/akashb/ews-script-to-automatically-generate-registry-keys-to-enable-custom-forms-in-outlook Tue, 14 Nov 2017 21:09:50 GMT https://blogs.msdn.microsoft.com/akashb/?p=1455
As you know Custom form script is now disabled by default and you will need to create a set of registry keys as outlined in this KB. We have had a few customers who have a lot of custom forms published in the Organizational Forms Library and it can be painful to get the message class of each of those form and then create the registry entries. The script below iterates through all the forms published in the Organizational Forms Library and then generates the required set of registry keys.

This is a PowerShell script that uses EWS Managed API Ver 2.2 to access the Organizational Forms Library and generate the registry keys. This script will need to be run with credentials of a user that has access to the Organizational Forms Library.

#
# DumpMessageClassforForms.ps1
#
# By Akash Bhargava, Microsoft Ltd. 2017. Use at your own risk.  No warranties are given.
# Thank you David for the Template
# DISCLAIMER:
# THIS CODE IS SAMPLE CODE. THESE SAMPLES ARE PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND.
# MICROSOFT FURTHER DISCLAIMS ALL IMPLIED WARRANTIES INCLUDING WITHOUT LIMITATION ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR OF FITNESS FOR
# A PARTICULAR PURPOSE. THE ENTIRE RISK ARISING OUT OF THE USE OR PERFORMANCE OF THE SAMPLES REMAINS WITH YOU. IN NO EVENT SHALL
# MICROSOFT OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF BUSINESS PROFITS,
# BUSINESS INTERRUPTION, LOSS OF BUSINESS INFORMATION, OR OTHER PECUNIARY LOSS) ARISING OUT OF THE USE OF OR INABILITY TO USE THE
# SAMPLES, EVEN IF MICROSOFT HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. BECAUSE SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION
# OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES, THE ABOVE LIMITATION MAY NOT APPLY TO YOU.
 
param (
    [Parameter(Mandatory=$False,HelpMessage="Username used to authenticate with EWS")]
    [string]$AuthUsername,
    
    [Parameter(Mandatory=$False,HelpMessage="Password used to authenticate with EWS")]
    [string]$AuthPassword,
    
    [Parameter(Mandatory=$False,HelpMessage="Domain used to authenticate with EWS")]
    [string]$AuthDomain,
 
    [Parameter(Mandatory=$False,HelpMessage="EWS Url (if omitted, then autodiscover is used)")]    
    [string]$EwsUrl,
    
    [Parameter(Mandatory=$False,HelpMessage="Path to managed API (if omitted, a search of standard paths is performed)")]    
    [string]$EWSManagedApiPath = "",
    
    [Parameter(Mandatory=$False,HelpMessage="Whether to ignore any SSL errors (e.g. invalid certificate)")]    
    [switch]$IgnoreSSLCertificate,
    
    [Parameter(Mandatory=$False,HelpMessage="Bitness of Outlook and Windows")]
    [string]$Bitness = "x32on64",
    
    [Parameter(Mandatory=$False,HelpMessage="Log file - activity is logged to this file if specified")]    
    [string]$LogFile = ""
    
)
 
[string]$info = "White"                # Color for informational messages
[string]$warning = "Yellow"            # Color for warning messages
[string]$error = "Red"                 #Color for error messages
[string]$success = "Green"             # Color for success messages
 
[string]$LogFile = "Log.txt"   # Path of the Log File
[string]$RegFile = "CustomFormKeys.reg"   # Path of the Reg File
 
 
# Define our functions
Function Log([string]$Details, [ConsoleColor]$Colour)
{
    if ($Colour -eq $null)
    {
        $Colour = [ConsoleColor]::White
    }
    
    if ($verbose)
    {    Write-Host $Details -ForegroundColor $Colour }
        
    if ( $LogFile -eq "" ) { return    }
    (Get-Date).ToString()+" "+ $Details | Out-File $LogFile -Append
}
 
Function LoadEWSManagedAPI()
{
    # Find and load the managed API
    
    if ( ![string]::IsNullOrEmpty($EWSManagedApiPath) )
    {
        if ( Test-Path $EWSManagedApiPath )
        {
            Add-Type -Path $EWSManagedApiPath
            return $true
        }
        Write-Host ( [string]::Format("Managed API not found at specified location: {0}", $EWSManagedApiPath) ) -ForegroundColor $error
    }
    
    $a = Get-ChildItem -Recurse "C:\Program Files (x86)\Microsoft\Exchange\Web Services" -ErrorAction SilentlyContinue | Where-Object { ($_.PSIsContainer -eq $false) -and ( $_.Name -eq "Microsoft.Exchange.WebServices.dll" ) }
    if (!$a)
    {
        $a = Get-ChildItem -Recurse "C:\Program Files\Microsoft\Exchange\Web Services" -ErrorAction SilentlyContinue | Where-Object { ($_.PSIsContainer -eq $false) -and ( $_.Name -eq "Microsoft.Exchange.WebServices.dll" ) }
    }
    
    if ($a)    
    {
        # Load EWS Managed API
        Write-Host ([string]::Format("Using managed API {0} found at: {1}", $a.VersionInfo.FileVersion, $a.VersionInfo.FileName)) -ForegroundColor $success
        Add-Type -Path $a.VersionInfo.FileName
        return $true
    }
    return $false
}
 
Function SearchOrganizationalFormsLibrary()
{
 
    # Set EWS URL if specified, or use autodiscover if no URL specified.
    if ($EwsUrl)
    {
        $service.URL = New-Object Uri($EwsUrl)
    }
    
    $LogExists = Test-Path $LogFile
    if ($LogExists){Remove-Item  $LogFile}
    
    $RegExists = Test-Path $RegFile
    if ($RegExists){Remove-Item  $RegFile}
    
    
    $nl = [Environment]::NewLine
    $RegFixFile = $null;
    
    if ($Bitness)
    {
        if ($Bitness -eq "x32on64")
        {
            $RegFixFile="Windows Registry Editor Version 5.00" + $nl + "[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Office\16.0\Outlook\Security]" + $nl + "`"DisableCustomFormItemScript`"=dword:00000000" + $nl +
            "[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Office\16.0\Outlook\Forms\TrustedFormScriptList]"
    
        }
        else
        {
            $RegFixFile="Windows Registry Editor Version 5.00" + $nl + "[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\16.0\Outlook\Security]" + $nl + "`"DisableCustomFormItemScript`"=dword:00000000" + $nl +
            "[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\16.0\Outlook\Forms\TrustedFormScriptList]"
        }
    }
            
        Log "Looking for Custom Forms.." $info 
    
    #Bind to the Public Folders Root
    $PFRoot = [Microsoft.Exchange.WebServices.Data.Folder]::Bind($service,[Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::PublicFoldersRoot)
    
    #$PFRoot
    #Get to Its Parent
    $ParentofPFRoot = [Microsoft.Exchange.WebServices.Data.Folder]::Bind($service,$PFRoot.ParentFolderId)
    
    #Folder View
    $oFolderView = new-object Microsoft.Exchange.WebServices.Data.FolderView(10)
    
    #Item View
    $PR_OAB_NAME = New-Object Microsoft.Exchange.WebServices.Data.ExtendedPropertyDefinition(0x6800,[Microsoft.Exchange.WebServices.Data.MapiPropertyType]::String);
    $oItemView = New-Object Microsoft.Exchange.WebServices.Data.ItemView(500)
    $oItemView.PropertySet = New-Object Microsoft.Exchange.WebServices.Data.PropertySet(
        [Microsoft.Exchange.WebServices.Data.BasePropertySet]::IdOnly,
        [Microsoft.Exchange.WebServices.Data.ItemSchema]::Subject,
        $PR_OAB_NAME)
    $oItemView.Traversal = [Microsoft.Exchange.WebServices.Data.ItemTraversal]::Associated
    
    $oFindFolderResults = $service.FindFolders($ParentofPFRoot.Id,$oFolderView)
    
    #Now Bind to the NON_IPM_SUBTREE
    $NON_IPM_SUBTREE = [Microsoft.Exchange.WebServices.Data.Folder]::Bind($service,$oFindFolderResults.Folders[1].Id)
    
    ForEach ($subFolder in $NON_IPM_SUBTREE.FindFolders($oFolderView))
    {
        
        if ($subFolder.DisplayName -eq "EFORMS REGISTRY")
        {
            #Get to the "Organizational Forms Library"
            $oFindFolderResultsOFL = $service.FindFolders($subFolder.Id,$oFolderView)
            
            #Look at the associated contents folder..
            $results = $service.FindItems( $oFindFolderResultsOFL.Folders[0].Id, $oItemView )
            
            $RegFixFile | Out-File $RegFile -Append
            
            Log "Looping through the Messages..."
            
            ForEach ($item in $results.Items)
            {
                $FormMessageClass =$null;
                if ($Item.TryGetProperty($PR_OAB_NAME,[ref] $FormMessageClass))
                {
 
                    #Generate the RegKeys..                
                    Log([string]::Format("Creating Key for :{0}", $FormMessageClass))
                    Write-Host ([string]::Format("Creating Key for :{0}", $FormMessageClass)) -ForegroundColor $success
            
                    '"' + $FormMessageClass +'"'+ "=" +'"' + '"' |Out-File $RegFile -Append
                }
            }
        }
    }
    
            
    Log "Done!"
}
 
Function TrustAllCerts() {
    <#
    .SYNOPSIS
    Set certificate trust policy to trust self-signed certificates (for test servers).
    #>
 
    ## Code From https://poshcode.org/624
    ## Create a compilation environment
    $Provider=New-Object Microsoft.CSharp.CSharpCodeProvider
    $Compiler=$Provider.CreateCompiler()
    $Params=New-Object System.CodeDom.Compiler.CompilerParameters
    $Params.GenerateExecutable=$False
    $Params.GenerateInMemory=$True
    $Params.IncludeDebugInformation=$False
    $Params.ReferencedAssemblies.Add("System.DLL") | Out-Null
 
    $TASource=@'
        namespace Local.ToolkitExtensions.Net.CertificatePolicy {
        public class TrustAll : System.Net.ICertificatePolicy {
            public TrustAll()
            { 
            }
            public bool CheckValidationResult(System.Net.ServicePoint sp,
                                                System.Security.Cryptography.X509Certificates.X509Certificate cert, 
                                                System.Net.WebRequest req, int problem)
            {
                return true;
            }
        }
        }
'@ 
    $TAResults=$Provider.CompileAssemblyFromSource($Params,$TASource)
    $TAAssembly=$TAResults.CompiledAssembly
 
    ## We now create an instance of the TrustAll and attach it to the ServicePointManager
    $TrustAll=$TAAssembly.CreateInstance("Local.ToolkitExtensions.Net.CertificatePolicy.TrustAll")
    [System.Net.ServicePointManager]::CertificatePolicy=$TrustAll
}
 
# The following is the main script
 
 
# Check if we need to ignore any certificate errors
# This needs to be done *before* the managed API is loaded, otherwise it doesn't work consistently (i.e. usually doesn't!)
if ($IgnoreSSLCertificate)
{
    Write-Host "WARNING: Ignoring any SSL certificate errors" -foregroundColor Yellow
    TrustAllCerts
}
 
# Load EWS Managed API
if (!(LoadEWSManagedAPI))
{
    Write-Host "Failed to locate EWS Managed API, cannot continue" -ForegroundColor $error
    Exit
}
 
#Create the service Object.
$service = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService([Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2010_SP1)
 
# Set credentials if specified, or use logged on user.
 if ($AuthUsername -and $AuthPassword)
 {
    Write-Host "Applying given Credentials for:", $AuthUsername -ForegroundColor $info
    if ($AuthDomain)
    {
        $service.Credentials = New-Object  Microsoft.Exchange.WebServices.Data.WebCredentials($AuthUsername,$AuthPassword,$AuthDomain)
    } else {
        $service.Credentials = New-Object  Microsoft.Exchange.WebServices.Data.WebCredentials($AuthUsername,$AuthPassword)
    }
 
} else {
    Write-Host "Using default credentials" -ForegroundColor Gray
    $service.UseDefaultCredentials = $true
 }
 
 
Write-Host ""
SearchOrganizationalFormsLibrary

By default the script will generate a .reg file for 32 bit Outlook on 64 bit Windows. If you want it for 64 bit Outlook on 64 bit Windows or 32 bit Outlook on 32 bit Windows, just specify -Bitness “x64on64” or -Bitness “x32on32”  in the command like below (technically an value other than “x32on64” will work). 

Sample command line below:

.\DumpMessageClassforForms.ps1 -AuthUsername admin –AuthPassword Pa$$w0rd –AuthDomain contoso -EwsUrl https://ex2013.contoso.com/ews/exchange.asmx
-IgnoreSSLCertificate

The registry file will be generated in the same folder where the script is run from.

Enjoy!]]> Generating a report - Which folders have a Personal Tag applied to it (using EWS Managed API from PowerShell - Exchange 2010) https://docs.microsoft.com/archive/blogs/akashb/generating-a-report-which-folders-have-a-personal-tag-applied-to-it-using-ews-managed-api-from-powershell-exchange-2010 Thu, 13 Jun 2013 13:49:48 GMT https://blogs.msdn.microsoft.com/akashb/2013/06/13/generating-a-report-which-folders-have-a-personal-tag-applied-to-it-using-ews-managed-api-from-powershell-exchange-2010/ It’s time to do a bit of reporting!

In my previous posts I have talked about Stamping Archive Policy Tag, Retention Policy Tag on Items, Retention Policy Tag on Folders but this time the requirement was different! In this case we wanted to scan the entire mailbox and find out the folders that have a Personal Tag applied to it.

To summarize what the script below does:

  • We search the entire mailbox and look for folders that have a Folder class of IPF.Note
  • Loop through the folders and write out the Folder Path, Retention Policy Tag GUID and the Retention Period
  • The log can then be opened in Excel and manipulated in any way you like!

Straight to code now. Create a .PS1 file with the code below: 

# The script requires the EWS managed API, which can be downloaded here:
# https://www.microsoft.com/en-us/download/details.aspx?id=35371
# This also requires PowerShell 2.0
# Make sure the Import-Module command below matches the DLL location of the API.
# This path must match the install location of the EWS managed API. Change it if needed.
[string]$info = "White"                # Color for informational messages
[string]$warning = "Yellow"            # Color for warning messages
[string]$error = "Red"                # Color for error messages
[string]$LogFile = "C:\Temp\Log.csv" # Path of the Log File
function SearchFolders($MailboxName)
{
    Write-host "Searching folders in Mailbox Name:" $MailboxName -foregroundcolor  $info
    
    #Change the user to Impersonate
    $service.ImpersonatedUserId = new-object Microsoft.Exchange.WebServices.Data.ImpersonatedUserId([Microsoft.Exchange.WebServices.Data.ConnectingIdType]::SmtpAddress,$MailboxName);
    #Number of Items to Get
    $FpageSize =50
    $FOffset = 0
    $MoreFolders =$true
    while ($MoreFolders)
     {

        #Setup the View to get a limited number of Items at one time
        $folderView = new-object Microsoft.Exchange.WebServices.Data.FolderView($FpageSize,$FOffset,[Microsoft.Exchange.WebServices.Data.OffsetBasePoint]::Beginning)
        $folderView.Traversal = [Microsoft.Exchange.WebServices.Data.FolderTraversal]::Deep
        
        # Folder Path
        $PR_FOLDER_PATH = new-object Microsoft.Exchange.WebServices.Data.ExtendedPropertyDefinition(26293, [Microsoft.Exchange.WebServices.Data.MapiPropertyType]::String);
        #PR_POLICY_TAG 0x3019
        $PolicyTag = New-Object Microsoft.Exchange.WebServices.Data.ExtendedPropertyDefinition(0x3019,[Microsoft.Exchange.WebServices.Data.MapiPropertyType]::Binary);
        #PR_RETENTION_FLAGS 0x301D    
        $RetentionFlags = New-Object Microsoft.Exchange.WebServices.Data.ExtendedPropertyDefinition(0x301D,[Microsoft.Exchange.WebServices.Data.MapiPropertyType]::Integer);
        
        #PR_RETENTION_PERIOD 0x301A
        $RetentionPeriod = New-Object Microsoft.Exchange.WebServices.Data.ExtendedPropertyDefinition(0x301A,[Microsoft.Exchange.WebServices.Data.MapiPropertyType]::Integer);

        $FPropertySet = new-object Microsoft.Exchange.WebServices.Data.PropertySet(
                            [Microsoft.Exchange.WebServices.Data.BasePropertySet]::IdOnly,
                            [Microsoft.Exchange.WebServices.Data.FolderSchema]::DisplayName,
                            [Microsoft.Exchange.WebServices.Data.FolderSchema]::FolderClass);
                            
        $FPropertySet.Add($PR_FOLDER_PATH);  
        $FPropertySet.Add($PolicyTag);
        $FPropertySet.Add($RetentionPeriod);
        
        $folderView.PropertySet = $FPropertySet;
        
        #Create the Search Filter.
        $FoSearchFilter = new-object Microsoft.Exchange.WebServices.Data.SearchFilter+IsEqualTo([Microsoft.Exchange.WebServices.Data.FolderSchema]::FolderClass, "IPF.Note")

        $oFindFolders = $service.FindFolders([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::MsgFolderRoot,$FoSearchFilter,$folderView)
        
        $PolicyTagString = $null;
        
        foreach ($folder in $oFindFolders.Folders)
        {
            Write-host "Looking at Folder:" $folder.ExtendedProperties[0].Value  -foregroundcolor $info;
      
            &{
                if ($folder.ExtendedProperties[1].Value -ne $null)
                {
                    $byteA =[byte[]]($folder.ExtendedProperties[1].Value)
                    $PolicyTagGUID = new-Object Guid(,$byteA);
                    $PolicyTagString = $PolicyTagGUID.ToString();
                }
                Add-Content $LogFile ($MailboxName + "," +$folder.ExtendedProperties[0].Value +"," +$PolicyTagString+"," +$folder.ExtendedProperties[2].Value);
            }
            trap [System.Exception] 
            {
                Write-host ("Error: " + $_.Exception.Message) -foregroundcolor $error;
                continue;
            }
        }

         if ($oFindFolders.MoreAvailable -eq $false)
            {$MoreFolders = $false}

             if ($MoreFolders)
            {$FOffset += $FpageSize}
        
     }

    Write-host "Finished with Mailbox Name:" $MailboxName "Done!" -foregroundcolor  $info
    Write-host "-------------------------------------------------" -foregroundcolor  $info

    $service.ImpersonatedUserId = $null
}
Import-Module -Name "C:\Program Files\Microsoft\Exchange\Web Services\2.0\Microsoft.Exchange.WebServices.dll"
$service = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService([Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2010_SP1)
# Set the Credentials
$service.Credentials = new-object Microsoft.Exchange.WebServices.Data.WebCredentials("ServiceAccount","password","domain")
# Change the URL to point to your cas server
$service.Url= new-object Uri("https://Your-CAS-Server/EWS/Exchange.asmx")
# Set $UseAutoDiscover to $true if you want to use AutoDiscover else it will use the URL set above
$UseAutoDiscover = $false
# Add headers to the log file
Add-Content $LogFile ("Mailbox" + "," +"Folder Path" +"," +" Retention Tag GUID" +"," +"Retention Period");
#Read data from the UserAccounts.txt
import-csv UserAccounts.txt | foreach-object {
    $WindowsEmailAddress = $_.WindowsEmailAddress.ToString()

    if ($UseAutoDiscover -eq $true) {
        Write-host "Autodiscovering.." -foregroundcolor $info
        $UseAutoDiscover = $false
        $service.AutodiscoverUrl($WindowsEmailAddress)
        Write-host "Autodiscovering Done!" -foregroundcolor $info
        Write-host "EWS URL set to :" $service.Url -foregroundcolor $info

    }
    #To catch the Exceptions generated
    trap [System.Exception] 
    {
        Write-host ("Error: " + $_.Exception.Message) -foregroundcolor $error;
        Add-Content $LogFile ("Error: " + $_.Exception.Message);
        continue;
    }
    SearchFolders($WindowsEmailAddress)
}

UserAccounts.txt contains the list of the users mailboxes that need to be searched. This file should exist in the same directory as the .PS1 file.The First row denotes the Field Names. Format of the text file is as below: 

WindowsEmailAddress
akasha@contoso.com
akashb@contoso.com
akashc@contoso.com

To Run the script: 
1)Open the Exchange Management Shell 
2)Navigate to the location where the script file is. 
3)Type in .\ScriptName.PS1 and hit enter to execute the script 
Note: This script creates a log file in C:\Temp. Make sure that directory exists.
Below is what the log file will look like:
Mailbox,Folder Path, Retension Tag GUID,Retension Period
akasha@contoso.com,\Deleted Items,,
akasha@contoso.com,\Drafts,,
akasha@contoso.com,\Inbox,,
akasha@contoso.com,\Inbox\Inbox1,4528ac9a-35b6-454d-96cb-c6801795bbce,300
akasha@contoso.com,\Inbox\Inbox1\Inbox2,4528ac9a-35b6-454d-96cb-c6801795bbce,300
akasha@contoso.com,\Junk E-Mail,,
akasha@contoso.com,\Outbox,,
akasha@contoso.com,\Sent Items,,
akasha@contoso.com,\Test,4528ac9a-35b6-454d-96cb-c6801795bbce,300
akashb@contoso.com,\Deleted Items,,
akashb@contoso.com,\Drafts,,
akashb@contoso.com,\Inbox,,
akashb@contoso.com,\Inbox\1,,
akashb@contoso.com,\Junk E-Mail,,
akashb@contoso.com,\Outbox,,
akashb@contoso.com,\Sent Items,,
Note the Folder Path and the GUID. What is this GUID? This is the Retention Policy Tag GUID!
Where can I get it from?
Open up Exchange Management Shell and run the command below:
[PS] C:\>Get-RetentionPolicyTag | FL Name,GUID
Output:
Name : Personal 1 Year move to archive
Guid : 797921d5-5c63-4a7b-b5d0-31e57a48f71b
Name : 1 Year Delete
Guid : 82139a14-cbf8-4467-9324-1c95c91bc12a
Name : Corp-BusinessCritical
Guid : 92186ff7-7f4d-4efa-a09b-bbdc5aee3908
Name : 100 Days - Delete
Guid : 3b7f5e7a-9016-4f87-a829-83f84c5adc62
Name : 300 Days Delete
Guid : 4528ac9a-35b6-454d-96cb-c6801795bbce


Now you know which Policy Tag was applied to the folder. Enjoy!

]]> All I know about Outlook 2010/2013 and SharePoint Synchronization https://docs.microsoft.com/archive/blogs/akashb/all-i-know-about-outlook-20102013-and-sharepoint-synchronization Fri, 05 Apr 2013 08:50:13 GMT https://blogs.msdn.microsoft.com/akashb/2013/04/05/all-i-know-about-outlook-20102013-and-sharepoint-synchronization/


When does Outlook 2010/2013 synchronies SharePoint Lists and Document Libraries?

By default, WSS lists can be synchronized once during each Send/Receive interval, and there are four basic ways to initiate this Send/Receive process in Outlook:

· Send/Receive (automatic or manual)
· Shift+F9 or F9
· Folder focus change
· Synchronize when Saving/Updating an Item

The All Accounts Send/Receive group has SharePoint list synchronization enabled by default and an automatic send/receive interval of 30 minutes. If you want to customize the default Send/Receive settings for your Outlook profile, Click on Send/Receive Tab, Click on Send/Receive Groups and then click Define Send/Receive Groups. The Send/Receive Groups dialog box is displayed.

clip_image001

Then, in the Send/Receive Groups dialog box select the All Accounts group and click Edit.The Send/Receive Settings – All Accounts dialog box is displayed.

All Accounts

The Send/Receive Settings – All Accounts dialog box contains two settings related to SharePoint list synchronization.

· Include Windows SharePoint lists in this Send/Receive group - With this checkbox enabled, every time the Send/Receive process is initiated for the Send/Receive group, the enabled SharePoint lists may be synchronized (depending on the Send/Receive update setting and the WSS automatic synchronization limit). If this checkbox is not enabled, then your SharePoint lists are not synchronized with Outlook during a Send/Receive operation. In this situation, you have to use different method for synchronizing the data.

· Send/Receive Options - Every SharePoint list configured on the SharePoint Lists tab of the Account Settings dialog box is listed under Send/Receive Options in the Send/Receive Settings – All Accounts dialog box. Only lists whose checkbox is enabled are synchronized whenever the synchronization process for the parent Send/Receive group is initiated.

Automatic Send/Receive Synchronization
In the Send/Receive Groups dialog box is a setting for All Accounts called Schedule an automatic send/receive every x minutes. When this x-minute interval expires, Outlook performs an automatic send/receive operation based on the settings you have configured for the All Accounts group in the Send/Receive Settings – All Accounts dialog box. If you disable SharePoint list synchronization via the Include Windows SharePoint lists in this Send/Receive group checkbox, or synchronization of specific SharePoint lists via the Send/Receive Options checkbox for the lists, then an automatic send/receive operation does not synchronize the WSS lists.

Manual Send/Receive Synchronization
There are several ways to perform a manual send/receive operation.

· Press F9
· Click Send/Receive All Folders on the Send/Receive Tab

If you have SharePoint synchronization enabled, then your SharePoint list should be synchronized whenever you use one of these manual send/receive operations.

If you disable SharePoint list synchronization via the Include Windows SharePoint lists in this Send/Receive group checkbox or you disable synchronization of specific SharePoint lists via the Send/Receive Options checkboxes, then your SharePoint lists are not synchronized when you use one of these manual send/receive operations. This occurs because these methods honor the settings you specify for the Send/Receive group.

Shift + F9
Using Shift+F9 is not technically classified as a Send/Receive operation because it does not utilize the settings you have for your Send/Receive group(s). Even if you disable SharePoint list synchronization via the Include Windows SharePoint lists in this Send/Receive group checkbox or synchronization of specific SharePoint lists via the Send/Receive Options checkboxes, your SharePoint list for the selected folder is still synchronized.

To initiate a manual synchronization of a SharePoint List folder, use the following steps.

· Select the folder for the WSS list or document library in the Folder List module.
· Press Shift + F9

Folder Focus Change
A third method of synchronizing a SharePoint list is to click off the folder for the list and then click back to it. This is another useful method if you disabled SharePoint list synchronization via the Include Windows SharePoint lists in this Send/Receive group checkbox or synchronization of specific SharePoint lists via the Send/Receive Options checkbox for the lists.

Synchronize when Saving an Item
To make collaboration a good user experience, Outlook automatically synchronizes your list if you add or edit a list item within the Outlook interface. Outlook does not wait for an automatic synchronization or a manual synchronization in this scenario and it only respects the server’s TTL value(We will look at what this is later in the article).

Does the STSSyncInterval registry key for Outlook control synchronization on Outlook 2010/2013?

The STSSyncInterval regkey corresponds to the "SharePoint folder sync interval" GPO which is included by default in the Outlook 2010/2013 adm template.

Although this is present, it is no longer used by Outlook.

How can we control the frequency of synchronization?

The Outlook client makes a call to the SharePoint Server to returns changes made to the specified list since the date and time specified in the token, if specified, or to return all the list items in the list. It uses the GetListItemChangesSinceToken operation. More details can be found in the article below:

Lists.GetListItemChangesSinceToken method
https://msdn.microsoft.com/en-us/library/websvclists.lists.getlistitemchangessincetoken.aspx

The following example shows a request that uses the change token extracted from a previous GetListItemChangesSinceTokenResponse: 

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="https://www.w3.org/2001/XMLSchema" xmlns:soap="https://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
    <GetListItemChangesSinceToken xmlns="https://schemas.microsoft.com/sharepoint/soap/">
        <listName>TestListItem</listName>
        <query><Query><OrderBy><FieldRef Name="ID"/></OrderBy></Query></query>
        <viewFields>
            <ViewFields>
                <FieldRef Name="ID" /><FieldRef Name="Title" />
            </ViewFields>
        </viewFields>
        <rowLimit>10</rowLimit>
        <changeToken> 1;3;e074e60a-0126-4446-a751-a5be7a55ed81;633374187828130000;243</changeToken>
    </GetListItemChangesSinceToken>
</soap:Body>
</soap:Envelope>

The response we get: 

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="https://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="https://www.w3.org/2001/XMLSchema">
<soap:Body>
    <GetListItemChangesSinceTokenResponse xmlns="https://schemas.microsoft.com/sharepoint/soap/">
        <GetListItemChangesSinceTokenResult>
            <listitems MinTimeBetweenSyncs='0' RecommendedTimeBetweenSyncs='180' MaxBulkDocumentSyncSize='500' AlternateUrls='https://siteaddress/' EffectivePermMask='FullMask' 
            xmlns:s='uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882' xmlns:dt='uuid:C2F41010-65B3-11d1-A29F-00AA00C14882' xmlns:rs='urn:schemas-microsoft-com:rowset' xmlns:z='#RowsetSchema'> 
            <Changes LastChangeToken="1;3;e074e60a-0126-4446-a751-a5be7a55ed81;633374187828130000;243"><List excluded content that matches GetList call … > </List></Changes> 
                <rs:data ItemCount="1"> 
                    <z:row ows_ID='1' ows_Title='Test new entry' ows_MetaInfo='1;#' ows__ModerationStatus='0' ows__Level='1' ows_owshiddenversion='3' ows_UniqueId='1;#{078CAB5C-5FEA-43EA-B23A-FB93EF35397D}' 
                    ows_FSObjType='1;#0' ows_Created='2008-01-28 08:06:11' ows_FileRef='1;#Lists/TestListItem/1_.000' />
                </rs:data>
            </listitems>
        </GetListItemChangesSinceTokenResult>
    </GetListItemChangesSinceTokenResponse>
</soap:Body>
</soap:Envelope>

Notice the MinTimeBetweenSyncs and the RecommendedTimeBetweenSyncs values returned, these values are used to control how synchronization works in Outlook.

By default, a SharePoint list does not have a publishing limit configured and the Current provider limit value in the SharePoint List Options dialog box will show Not Published. Therefore, by default, you can manually synchronize your WSS list data with Outlook as often as you want. 
Where can I see this in the Outlook UI? You can go to Account Settings, then to the SharePoint Lists Tab and then double click on the list you are interested in.
xxx
The MinTimeBetweenSyncs represents the minimum amount of time between user-initiated or automatic synchronization. The value represents a time in minutes.

Clients should respect this value even if the user initiates synchronization manually. That is, if this is set to 5 minutes, clients should only send one request per 5 minutes even if the user repeatedly clicks "send/receive".

This setting is also known TTL and the property name that needs to be set on the SharePoint server is “min-time-between-syncs”. The default value for this property is 0 minutes. How do we set it on the SharePoint Server?

To set this value on the server, use the STSADM interface on the SharePoint server. The general syntax for setting a property is:
stsadm -o setproperty –propertyname <property name> -propertyvalue <property value>
So in this case:
STSADM -o setproperty - propertyname "min-time-between-syncs" - propertyvalue "0"
Users can prevent their clients from honoring the TTL value you specify by clearing the Update Limit checkbox in the SharePoint List Options dialog box for a list. However, you can also set policy key to force Outlook clients to respect the TTL value published by WSS.
The policy is called “Override published sync interval”.

Registry Key: software\policies\microsoft\office\14.0\outlook\options\wss
Registry Value Name:IgnoreTTL
Registry Value: 1 or 0
Description: This policy setting allows you to prevent users from overriding the sync interval published by managed SharePoint lists. If you enable this policy setting, the ''Update Limit'' checkbox found under File tab | Info | Account Settings | SharePoint List | Change& is disabled, and the user's connected SharePoint lists will only sync as defined by the list's administrator. If you disable this policy setting, then individual users will be able to override the sync interval by unchecking the ''Update Limit'' checkbox in the SharePoint List's Options dialog.

However, there is a different server synchronization limit that is used for automatic synchronizations initiated by an Outlook Send/Receive operation. The default limit for automatic synchronizations by Outlook is 180 minutes.
This setting is also known ASI and the property name that needs to be set on the SharePoint server is “recommended-time-between-syncs”. The default value for this property is 180. How do we set it on the SharePoint Server?
To set this value on the server, use the STSADM interface on the SharePoint server. The general syntax for setting a property is:
stsadm -o setproperty –propertyname <property name> -propertyvalue <property value>
So in this case:
STSADM -o setproperty - propertyname "recommended-time-between-syncs" - propertyvalue "60"
When the “recommended-time-between-syncs” is set on the server, Outlook will synchronize the lists once in 60 minutes(as set in the example above) even when automatic synchronizations is scheduled to happen in 30 minutes by default.
If users synchronize too often with the SharePoint server or they complain that the automatic synchronization interval is too long, you can adjust the ASI and the TTL values on the server to better suit the needs of your users. 
Enjoy!
]]> Images sent using Snipping Tool(SnippingTool.exe) shows up as RED X in Outlook 2010 https://docs.microsoft.com/archive/blogs/akashb/images-sent-using-snipping-toolsnippingtool-exe-shows-up-as-red-x-in-outlook-2010 Fri, 07 Dec 2012 14:09:04 GMT https://blogs.msdn.microsoft.com/akashb/2012/12/07/images-sent-using-snipping-toolsnippingtool-exe-shows-up-as-red-x-in-outlook-2010/ This was an interesting issue, the customer was using the Snipping Tool to capture images and mail them. He would simply get a capture and then do a File->Send To-> E-mail Recipient in the Snipping Tool, this opened an E-mail in Outlook and everything looked fine.

image

When the email was sent and received, the Image showed up as a Red X with the message “The linked image cannot be displayed. The file may have been moved, renamed, or deleted. Verify that the link points to the correct file and location.”

image

An Interesting fact was that this worked fine in the following scenarios:
1) When Outlook was run in Safe mode
2) If the image was copied and pasted in the e-mail instead of using the Snipping Tool

We look at the HTML of the email and noticed that the img tag was pointing to a physical path to the Image file! This is never going to work since the same path+Image would never exist on the recipients machine. Below is what the body looked like: 

<body lang=EN-US link=blue vlink=purple>
    <div class=WordSection1><p class=MsoNormal>
        <span style='font-family:"Arial","sans-serif"'>
            <img border=0 width=866 height=306 id="_x0000_i1025" src="file:///C:\Users\AKASH\AppData\Local\Temp\SnipImage-%7b91EAD0DB-1DBE-4E4A-B24B-F9CAB854BE82%7d.PNG">
    </span><br></p>
    </div>
</body>

What should it have looked like? 
<body lang=EN-US link=blue vlink=purple style='tab-interval:.5in'>
    <div class=WordSection1><p class=MsoNormal>
        <img width=661 height=205 id="_x0000_i1025" src="cid:image001.png@01CDD4E9.F5F9A6E0">
        </p>
    </div>
</body>
 
In short, a link to the image was being sent instead of the image being sent with the mail. Why did this happen?

Process Monitor finally came to the rescue. Reviewing the logs we found that the “Send Pictures With Document” registry key was set to 0. i.e Outlook would send a link instead of including the picture with the message. More details on the key: 
Key: HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\Options\Mail
Value type: REG_DWORD
Value name; Send Pictures With Document
Value: 0
 
If the Value is set to 1 or the key is not present, the picture is embedded as an hidden attachment pointed to by the Content-ID(cid).  Why did it work in Safe mode? In Safe mode Outlook ignores certain registry settings and sometimes takes a different code path!
 
Enjoy!

]]> Stamping Archive Policy Tag using EWS Managed API from PowerShell(Exchange 2010) https://docs.microsoft.com/archive/blogs/akashb/stamping-archive-policy-tag-using-ews-managed-api-from-powershellexchange-2010 Fri, 07 Dec 2012 09:16:00 GMT https://blogs.msdn.microsoft.com/akashb/2012/12/07/stamping-archive-policy-tag-using-ews-managed-api-from-powershellexchange-2010/ In a previous post I had explained how to stamp a Retention Policy Tag using EWS Managed API, In this post I will explain the changes you will need to make to stamp an Archive Policy Tag. What’s the difference between these two? Retention Policies consist of delete tags, i.e. retention tags with either Delete and Allow Recovery or Permanently Delete actions, or archive tags, i.e. retention tags with the Move To Archive action, which move items to the user's archive mailbox.

The requirement in this case to prevent the items in the notes folder from being moved to the Archived folder, a detailed explanation of the issue can be found here. Why is the Notes folder part of the issue? In Exchange 2010 SP1, support was added for the Notes folder. In Exchange 2010 RTM, items in the Notes folder aren't processed. After upgrade to SP1, if the user's retention policy doesn't have a Retention Policy Tag for the Notes folder, the Default Policy Tags from the user's policy will apply to items in that folder.

In short the workaround is to have users apply the Personal never move to archive personal tag (displayed as Never under Archive Policy in Outlook/OWA) to a default folder(Notes in this case). How do this archive personal tag look like? Below is a screenshot:

image

Now that we have the Archive Policy Tag in place, we have to make a few changes in the code to get this to work. Most of the need code is the same as in the Retention Policy Tag using EWS Managed API article. The change is in the “StampPolicyOnFolder” function which I have detailed below:

function StampPolicyOnFolder($MailboxName)
{
Write-host "Stamping Policy on folder for Mailbox Name:" $MailboxName -foregroundcolor $info
Add-Content $LogFile ("Stamping Policy on folder for Mailbox Name:" + $MailboxName)

#Change the user to Impersonate
$service.ImpersonatedUserId = new-object Microsoft.Exchange.WebServices.Data.ImpersonatedUserId([Microsoft.Exchange.WebServices.Data.ConnectingIdType]::SmtpAddress,$MailboxName);

#Search for the folder you want to stamp the property on
$oFolderView = new-object Microsoft.Exchange.WebServices.Data.FolderView(1)
$oSearchFilter = new-object Microsoft.Exchange.WebServices.Data.SearchFilter+IsEqualTo([Microsoft.Exchange.WebServices.Data.FolderSchema]::DisplayName,$FolderName)
$oFindFolderResults = $service.FindFolders([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::MsgFolderRoot,$oSearchFilter,$oFolderView)

if ($oFindFolderResults.TotalCount -eq 0)
{
       Write-host "Folder does not exist in Mailbox:" $MailboxName -foregroundcolor $warning
       Add-Content $LogFile ("Folder does not exist in Mailbox:" + $MailboxName)
}
else
{
       Write-host "Folder found in Mailbox:" $MailboxName -foregroundcolor $info

       #PR_ARCHIVE_TAG 0x3018 – We use the PR_ARCHIVE_TAG instead of the PR_POLICY_TAG
       $ArchiveTag = New-Object Microsoft.Exchange.WebServices.Data.ExtendedPropertyDefinition(0x3018,[Microsoft.Exchange.WebServices.Data.MapiPropertyType]::Binary);

       #PR_RETENTION_FLAGS 0x301D
       $RetentionFlags = New-Object Microsoft.Exchange.WebServices.Data.ExtendedPropertyDefinition(0x301D,[Microsoft.Exchange.WebServices.Data.MapiPropertyType]::Integer);

       #PR_ARCHIVE_PERIOD 0x301E - We use the PR_ARCHIVE_PERIOD instead of the PR_RETENTION_PERIOD
       $ArchivePeriod = New-Object Microsoft.Exchange.WebServices.Data.ExtendedPropertyDefinition(0x301E,[Microsoft.Exchange.WebServices.Data.MapiPropertyType]::Integer);

       #Change the GUID based on your policy tag
       $ArchiveTagGUID = new-Object Guid("{3b7f5e7a-9016-4f87-a829-83f84c5adc62}");

       #Bind to the folder found
       $oFolder = [Microsoft.Exchange.WebServices.Data.Folder]::Bind($service,$oFindFolderResults.Folders[0].Id)

       #Same as that on the policy - 16 specifies that this is a ExplictArchiveTag
       $oFolder.SetExtendedProperty($RetentionFlags, 16)

       #Same as that on the policy - Since this tag is disabled the Period would be 0
       $oFolder.SetExtendedProperty($ArchivePeriod, 0)

       $oFolder.Update()

       Write-host "Retention policy stamped!" -foregroundcolor $info
       Add-Content $LogFile ("Retention policy stamped!")
}

$service.ImpersonatedUserId = $null
}
#Change the name of the folder. This is the folder the properties will be stamped on.
$FolderName = "Notes"


With the above changes, you can now stamp an Archive Policy tag on multiple mailboxes and AFAIK there is no admin-controlled way of doing this. Once again, Thank you Vikas Soundade(Exchange) for helping me with the MRM piece!
Enjoy!
]]> Outlook displaying the Red X mark instead of the Image https://docs.microsoft.com/archive/blogs/akashb/outlook-displaying-the-red-x-mark-instead-of-the-image Fri, 31 Aug 2012 11:23:25 GMT https://blogs.msdn.microsoft.com/akashb/2012/08/31/outlook-displaying-the-red-x-mark-instead-of-the-image/ This was a fun issue to troubleshoot! The problem : Compose a new mail in Outlook 2010, Insert a image and send it to yourself. The expected behavior is that when you open the received mail, you see the Image.

In this case, instead of the Image we saw Red X mark with the message “The linked image cannot be displayed.  The file may have been moved, renamed, or deleted. Verify that the link points to the correct file and location.”

image

The interesting part was that everything worked fine in Safe mode! What could be causing this issue?
In general, when we open an Item that has embedded images, the images are copied to a temp location which is then used for displaying the image. When the Item is closed the Images are deleted from that location. On further troubleshooting and debugging the issue, we noticed that in this case the Images never got created!

Knowing this was a BIG help to track down this issue. The question: Where is the temp location picked up from and does it really exist? On debugging we found that Outlook was reading the value from the follow key: 

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\Cache

The value that was read in this case was %CACHEDIR%\Cache . Is this the right value? I guess NOT. In a working case it gives us the full path to the Temporary Internet Files, something like “C:\Documents and Settings\username\Local Settings\Temporary Internet Files”
When I looked at a few machine in my environment the values were as below:
On a Windows XP machine: %USERPROFILE%\Local Settings\Temporary Internet Files
On a Windows 7 machine: %USERPROFILE%\AppData\Local\Microsoft\Windows\Temporary Internet Files
 
In this case the problem machine was a Windows XP machine, we replaced %CACHEDIR%\Cache with %USERPROFILE%\Local Settings\Temporary Internet Files and then restarted Outlook.
Now everything WORKS?

Why did it work in Safe mode? In Safe mode, Outlook takes a different code path and a different API to get the temp folder location and does that successfully!
Enjoy!

]]> Exchange 2013 Preview is now AVAILABLE! https://docs.microsoft.com/archive/blogs/akashb/exchange-2013-preview-is-now-available Fri, 03 Aug 2012 14:49:11 GMT https://blogs.msdn.microsoft.com/akashb/2012/08/03/exchange-2013-preview-is-now-available/
Download Microsoft Exchange Server 2013 Preview
https://technet.microsoft.com/en-US/evalcenter/hh973395

Developer Resources for Exchange 2013

EWS client design overview for Exchange 2013
https://msdn.microsoft.com/en-us/library/jj190904(EXCHG.150).aspx

Exchange Web Services Managed API Version 2.0 - Technical Preview
https://www.microsoft.com/en-us/download/details.aspx?id=30391

New features in EWS in Exchange 2013
https://msdn.microsoft.com/en-us/library/jj190903(EXCHG.150).aspx

New features in the EWS Managed API
https://msdn.microsoft.com/en-us/library/jj220500(EXCHG.80).aspx

Exchange 2013 101 Code Samples
https://code.msdn.microsoft.com/Exchange-2013-101-Code-3c38582c

Get started with mail apps for Outlook 2013 and EWS in Exchange 2013
https://msdn.microsoft.com/en-us/library/jj190901(EXCHG.150).aspx

Enjoy!

]]> Using–Filter, Select-Object, ForEach-Object in C# – Exchange PowerShell Automation https://docs.microsoft.com/archive/blogs/akashb/usingfilter-select-object-foreach-object-in-c-exchange-powershell-automation Wed, 01 Aug 2012 13:24:32 GMT https://blogs.msdn.microsoft.com/akashb/2012/08/01/usingfilter-select-object-foreach-object-in-c-exchange-powershell-automation/ Have you ever tried migrating Exchange PowerShell script to be used from C# code?  I needed to convert the following script to C# 

Get-Mailbox -filter {ResourceType -ne "Room"}| Select-object Alias,DistinguishedName,Identity | foreach-object {Get-MailboxFolderStatistics $_.Alias}

If you run the above script in Exchange 2010 Management Shell you might get the following error message: 

Pipeline not executed because a pipeline is already executing. Pipelines cannot be executed concurrently.
    + CategoryInfo          : OperationStopped: (Microsoft.Power...tHelperRunspace:ExecutionCmdletHelperRunspace) [],
   PSInvalidOperationException
    + FullyQualifiedErrorId : RemotePipelineExecutionFailed

  This error is caused because the Windows PowerShell remoting feature doesn't support more than one pipeline running at the same time. To resolve this issue, store the output of the cmdlet earlier in the pipeline in a variable, and then pipe the data stored in the variable to the ForEach cmdlet as shown below: 

$Mailboxes = Get-Mailbox -filter {ResourceType -ne "Room"}| Select-object Alias,DistinguishedName, Identity 
$Mailboxes | foreach-object {Get-MailboxFolderStatistics $_.Identity}

Now, to get the code working in C#. How do I use the Filter ? How do I use the Select-Object ? How do I store the intermediate result and then pass it into the ForEach-Object? The below code snippet shows how this can be done. I you need a full example of using Exchange PowerShell from C#, you can find it here . 

//TODO: Create and Open Runspace, Create and Import Session
 //Create a pipline
 Pipeline pipe = runspace.CreatePipeline();
 //Add the first command Get-Mailbox with the filters
 Command CommandGetMailbox = new Command("Get-Mailbox");
 CommandGetMailbox.Parameters.Add("Filter", "ResourceType -ne \"Room\"");
 pipe.Commands.Add(CommandGetMailbox);
 // Do a Select-Object on the fields
 var props = new string[] { "Alias", "DistinguishedName", "Identity"};
 Command CommandSelect = new Command("Select-Object");
 CommandSelect.Parameters.Add("Property", props);
 pipe.Commands.Add(CommandSelect);
 //Invoke the First Pipeline and get the results
 resultMailboxes = pipe.Invoke();
 // Create a second Pipeline..
 Pipeline pipe2 = runspace.CreatePipeline();
 // Do a write-output of the results so that it can be piped to the foreach
 Command Command1 = new Command("write-output");
 Command1.Parameters.Add("InputObject", resultMailboxes);
 pipe2.Commands.Add(Command1);
 //Pipe into the ForEach
 Command CommandForEach = new Command("ForEach-Object");
 CommandForEach.Parameters.Add("Process", ScriptBlock.Create("Get-MailboxFolderStatistics -Identity $_.Identity"));
 pipe2.Commands.Add(CommandForEach);
 //Invoke the second Pipeline..
 resultMailboxes = pipe2.Invoke();
 //TODO: Display the results and clean up

Enjoy!




]]> EWS Managed API is lying to me! https://docs.microsoft.com/archive/blogs/akashb/ews-managed-api-is-lying-to-me Fri, 20 Jul 2012 12:19:00 GMT https://blogs.msdn.microsoft.com/akashb/2012/07/20/ews-managed-api-is-lying-to-me/ I have been working with Exchange Web Services(EWS) for a long time and this is the first time I saw that the EWS was lying to me! The code was executing a FindItem call on a list of folders and all of a sudden it threw the following error: “Error occurred: The request failed. The remote server returned an error: (401) Unauthorized”.

Why would that happen? If it was an authentication problem then why did my previous call work? The first step was to check the IIS Logs on the CAS server and below is what we find:

7/11/2012  10.171.230.40    POST /EWS/Exchange.asmx    SoapAction=FindItem 443    ExchangeServicesClient/14.03.0067.001    200     63025
7/11/2012  10.171.230.40    POST /EWS/Exchange.asmx    SoapAction=FindItem 443    ExchangeServicesClient/14.03.0067.001    200     21809
7/11/2012  10.171.230.40    POST /EWS/Exchange.asmx    SoapAction=FindItem 443    ExchangeServicesClient/14.03.0067.001    302     196752
7/11/2012  10.171.230.40    POST /EWS/Exchange.asmx    SoapAction=FindItem 443    ExchangeServicesClient/14.03.0067.001    302     196643

I chose to show only the relevant columns above. I you notice the highlighted values, the 302 is the HTTP Status code which means that the object has been temporarily moved. The last column is the time taken in milliseconds to execute the FindItem request. In the above case it was more than 3 minutes which is not good and means we have a LOTS of scope to optimize the code.

But, why do I get the 302? I turned my attention to the Event Logs on the CAS box and I did not have to search too much. Below is what I saw:

Log Name:      Application
Source:        ASP.NET 2.0.50727.0
Date:          7/11/2012 12:58:05 PM
Event ID:      1309
Task Category: Web Event
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      myserver.contoso.com
Description:
Event code: 3001 
Event message: The request has been aborted. 
Event time: 7/11/2012 12:58:05 PM 
Event time (UTC): 7/11/2012 4:58:05 PM 
Event ID: 38a627eada914200923e244e9c83f7c8 
Event sequence: 6230694 
Event occurrence: 37 
Event detail code: 0 
 
Application information: 
    Application domain: /LM/W3SVC/1/ROOT/EWS-1-129851299999841294 
    Trust level: Full 
    Application Virtual Path: /EWS 
    Application Path: C:\Program Files\Microsoft\Exchange Server\ClientAccess\exchweb\EWS\ 
    Machine name: myserver
 
Process information: 
    Process ID: 1152 
    Process name: w3wp.exe 
    Account name: NT AUTHORITY\SYSTEM 
 
Exception information: 
    Exception type: HttpException 
    Exception message: Request timed out. 
 
Request information: 
    Request URL: https://myserver.contoso.com:443/EWS/Exchange.asmx 
    Request path: /EWS/Exchange.asmx 
    User host address: 10.171.230.40 
    User: DOMAIN\Username 
    Is authenticated: True 
    Authentication Type: Negotiate 
    Thread account name: NT AUTHORITY\SYSTEM 
 
Thread information: 
    Thread ID: 26 
    Thread account name: NT AUTHORITY\SYSTEM 
    Is impersonating: False 
    Stack trace:

Now the picture is clearer! Since the request was running for more that 110 seconds which is default timeout in ASP.NET 2.0, the request was being aborted, which resulted in a 302 in the IIS logs. Now why did EWS Managed API return 401, frankly I did not bother to find!

To validate the cause we went ahead and increased the executionTimeout from 110 to 240 in the Web.Config for EWS and then we did not see the issue any more. This was done for TESTING only and is definitely not recommended.

There are two possible solutions to this issue:
1) Optimize your code and use filters and paging while doing FindItems (Recommended).
2) Increase the executionTimeout setting in the Web.Config(Not Recommended – can be tried only If optimization does not work ).

Enjoy!

]]> Unable to send Bcc using System.Net.Mail when specifying a Pickup Directory(Exchange 2007/Exchange 2010) in code https://docs.microsoft.com/archive/blogs/akashb/unable-to-send-bcc-using-system-net-mail-when-specifying-a-pickup-directoryexchange-2007exchange-2010-in-code Thu, 19 Jul 2012 15:49:38 GMT https://blogs.msdn.microsoft.com/akashb/2012/07/19/unable-to-send-bcc-using-system-net-mail-when-specifying-a-pickup-directoryexchange-2007exchange-2010-in-code/ Not sure developers using System.Net.Mail are not complaining about this issue? The issue is very easy to reproduce, all you need to do is create a new mail with someone on Bcc and drop it to the Pickup folder In Exchange. Most likely not to many people use Bcc or use Port instead of Pickup.

MailMessage message = new MailMessage("User1@mycompany.com", "User2@mycompany.com", "Sent Using Pickup", "This Message was sent using Pickup");
message.Bcc.Add(new MailAddress("User3@mycompany.com"));
SmtpClient client = new SmtpClient();
client.DeliveryMethod = SmtpDeliveryMethod.SpecifiedPickupDirectory;
client.PickupDirectoryLocation = @"C:\Program Files\Microsoft\Exchange Server\TransportRoles\Pickup";
client.Send(message);

If we send a mail using the above code we would expect that the mail gets delivered to the Bcc user i.e User3@mycompany.com, but that does not happen! Why would that happen? I then tried to use CDOSYS to create a mail and added Bcc to it and this time the mail was delivered to User3@mycompany.com.

What could the difference be? I stopped the Transport service on my Exchange 2007(installed on Windows 2003) so that the mail do not get delivered by the transport and then examined the .eml to check what the difference could be. Below is what I find:

System.Net.Mail uses X-Headers to add the Recipient information to the mail.Below is what the MIME look like on my Windows 2003 box: 

X-Sender: User1@mycompany.com
X-Receiver: User2@mycompany.com
X-Receiver: User3@mycompany.com <- This is the BCC
MIME-Version: 1.0
From: User1@mycompany.com
To: User2@mycompany.com
Date: 19 Jul 2012 13:53:05 -0400
Subject: Sent Using Pickup
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

This Message was sent using Pickup

Below is what the MIME looks like when I used CDOSYS on my Windows 2003 box: 
thread-index: Ac1l181oBFqzycOSRFaCD7mjVftgqw==
Thread-Topic: This is a test CDOSYS message (Sent via Pickup)
From: <User1@mycompany.com>
To: <User2@mycompany.com>
Bcc: <User3@mycompany.com>
Subject: This is a test CDOSYS message (Sent via Pickup)
Date: Thu, 19 Jul 2012 13:56:20 -0400
Message-ID: <D76CF8D778AE43A096B10F2281A9914F@mycompany.com>
MIME-Version: 1.0
...

If you notice, the above MIME does not use X-Headers, it uses the Bcc header and it works. Unfortunately, this behavior of CDOSYS could be different on different environments. When I tested on a Windows 7 box, the MIME looks very similar to what we get from System.Net.Mail(uses X-Header).
Based on my discussion with the Exchange guys, it turns out that when the mail is put in the Pickup folder, it does not look at the X-Headers and uses the From, To, Bcc headers if present.
 
The simplest solution was to drop the mail in the Replay folder instead of the Pickup folder.
MailMessage message = new MailMessage("User1@mycompany.com", "User2@mycompany.com", "Sent Using Pickup", "This Message was sent using Pickup");
message.Bcc.Add(new MailAddress("User3@mycompany.com"));
SmtpClient client = new SmtpClient();
client.DeliveryMethod = SmtpDeliveryMethod.SpecifiedPickupDirectory;
client.PickupDirectoryLocation = @"C:\Program Files\Microsoft\Exchange Server\TransportRoles\Replay";
client.Send(message);
 
Below is an article that talks about both the directories, although it does not mention that X-Headers are ignored in the pickup, it does explicitly say that Replay makes use of the X-Headers.

Understanding the Pickup and Replay Directories
https://technet.microsoft.com/en-us/library/bb124230.aspx

I have tested this on Exchange 2007 installed on Windows 2003 and it works!
Enjoy!


]]>