December, 2012

  • Akash Blogging......

    Images sent using Snipping Tool(SnippingTool.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.


    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.”


    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">

    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">
    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!

  • Akash Blogging......

    Stamping Archive Policy Tag using EWS Managed API from PowerShell(Exchange 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:


    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)
           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)


           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!
Page 1 of 1 (2 items)