Skip to main content

Simple scripted download Attachment using the Graph or Outlook Rest API in Office365

This is a rewrite of one of the more popular EWS posts (original post) on my blog about creating a scripted process that would download attachments from an email with a particular subject line in the Inbox and then mark that email read and move it to another folder in the Mailbox. In this post I'm going to go through a direct one to one rewrite of this script and talk about the comparisons between how you used the operations in EWS and now how you can do the same thing using the Graph or Outlook REST API. In another post I'll show an enhanced version that allows you to use the Graph API to save the attachment into another Graph endpoint such as OneDrive or SharePoint.

For this script I'm using the Exch-Rest Module I'm currently building which is available on the powershellgallery https://www.powershellgallery.com/packages/Exch-Rest and the source from Github https://github.com/gscales/Exch-Rest. For this script I had to overcome an issue with the ConvertFrom-Json Cmdlet which has an issue once the JSON payload gets over 2 MB so an alternate method in the REST code was needed to allow for attachment downloads of over 2MB.

Step 1: Loading the Module, Setting up variables for the script and Getting the Access Token

Import-Module Exch-Rest -Force
$MailboxName = "user@domain.onmicrosoft.com"
$Subject = "Daily Export"
$ProcessedFolderPath = "\Inbox\Processed"
$downloadDirectory = "c:\temp"
##Get the Access Token
$AccessToken =  Get-AccessToken -MailboxName $MailboxName  -ClientId 5471030d-f311-4c5d-91ef-74ca885463a7 -redirectUrl "urn:ietf:wg:oauth:2.0:oob" -ResourceURL graph.microsoft.com         

The first step in the scripted process is to load the module then setup some variables to hold which mailbox to access, the subject of the Message to search for and the folder to move the message to once its has been processed. Then finally we have the code to get the oauth AccessToken,with getting the Access Token there are few different options described here you need to choose the most appropriate one for you depending on how you are going to implement this in your environment. The EWS equivalent here would have been loading the Managed API, authenticating and doing an Autodiscover

Step 2: Search for the Items in the Inbox that are Unread, Have Attachments and the Subject line "Daily Export"
 
$Filter = "IsRead eq false AND HasAttachments eq true AND Subject eq '" + $Subject + "'"
$Items = Get-FolderItems -MailboxName $MailboxName -AccessToken $AccessToken -FolderPath \Inbox -Filter $Filter
In the REST API like EWS there are two different ways of searching for items
  • Filter
In EWS this was done using the SearchFilters Class (or a restriction in EWS proxy code) in REST this is done using the OData parameter $filter. The underlying mechanism the Exchange store uses for both EWS and REST to filter items and returned results is based on Restrictions (I still like the explanations in this article as to how they work https://technet.microsoft.com/en-us/library/cc535025(v=exchg.80).aspx) . Using Filters gives you the most flexibility when it comes to finding particular items based on particular properties but this does come at the cost of performance. You should try not to over complicate your filters too much as like any database your performance and application will suffer if the filters are written poorly with no regards to data structure or quantity.
  • Content Index Searches
In EWS a content index search could be done using AQS (Advance Query Syntax) and the QueryString Element in the FindItem operation. In REST you use the $Search OData parameter https://msdn.microsoft.com/en-us/office/office365/api/complex-types-for-mail-contacts-calendar#OdataQueryParams and the same AQS syntax you use in EWS. These searches should yield much better performance when you are searching folders with much higher Item counts because they utilize the Content indexes. There are limitations around using Search however because only certain properties are indexed and available for use (see https://technet.microsoft.com/en-us/library/jj983804(v=exchg.150).aspx) and there can be a delay in Indexes being updated.

I've used the $filter parameter in my above example which reflects the SearchFilter used in EWS in the original post but Search could also be used in this example.

Step 3: Processing the Attachments on the Items

Get-Attachments -MailboxName $MailboxName -ItemURI $item.ItemRESTURI -MetaData -AccessToken $AccessToken | ForEach-Object{
$attach = Invoke-DownloadAttachment -MailboxName $MailboxName -AttachmentURI $_.AttachmentRESTURI -AccessToken $AccessToken
$fiFile = new-object System.IO.FileStream(($downloadDirectory  + "\" + $attach.Name.ToString()), [System.IO.FileMode]::Create)
$attachBytes = [System.Convert]::FromBase64String($attach.ContentBytes)   
$fiFile.Write($attachBytes, 0, $attachBytes.Length)
$fiFile.Close()
write-host ("Downloaded Attachment : " + (($downloadDirectory + "\" + $attach.Name.ToString())))
 Like EWS when you enumerate the Items in folder using REST it won't return all the information about the Item for performance reasons. So like EWS where you would then use a GetItem request to get the Metadata information about attachments in REST you need to do a simular thing before you can proceed to downloading the attachment. In the module I have the Get-Attachments function for returning the MetaData about attachments (this writes a custom AttachmentRESTURI property into the results). Then the Invoke-DownloadAttachment function does the downloading of the attachments content. If the message has more then one attachment this is where you would modify the code to do additional processing (eg restriction on FileName, FileType etc).

Step4: Marking the Item as Read

$UpdateProps = @()
$UpdateProps += (Get-ItemProp -Name IsRead -Value true -NoQuotes)
Update-Message -MailboxName $MailboxName -AccessToken $AccessToken -ItemURI $item.ItemRESTURI -StandardPropList $UpdateProps
In EWS to mark an Item as read you would update the IsRead Strongly typed property and then call UpdateItem operation. In REST it is much the same procedure except we have some code that defines the Property you want to update in JSON (in this case the isRead property) and then it uses a HTTP Patch request to send the update to the server along with the URI of the Item you are updating.

Step5: Moving the Item to another folder

Move-Message -MailboxName $MailboxName -ItemURI $item.ItemRESTURI -TargetFolderPath $ProcessedFolderPath -AccessToken $AccessToken     
 In EWS to move an Item to another folder you use the MoveItem operation, in REST its fairly simular you invoke a move by sending the URI of the Item with /move appended to the end with a JSON payload of destination FolderId https://msdn.microsoft.com/en-us/office/office365/api/mail-rest-operations#move-or-copy-messages which is what Move-Message function does in the Module.

that's pretty much it I've posted the full code for this sample on GitHub here https://github.com/gscales/Exch-Rest/blob/master/Samples/simpleAttachDownload.ps1
 

Popular posts from this blog

Testing and Sending email via SMTP using Opportunistic TLS and oAuth in Office365 with PowerShell

As well as EWS and Remote PowerShell (RPS) other mail protocols POP3, IMAP and SMTP have had OAuth authentication enabled in Exchange Online (Official announcement here ). A while ago I created  this script that used Opportunistic TLS to perform a Telnet style test against a SMTP server using SMTP AUTH. Now that oAuth authentication has been enabled in office365 I've updated this script to be able to use oAuth instead of SMTP Auth to test against Office365. I've also included a function to actually send a Message. Token Acquisition  To Send a Mail using oAuth you first need to get an Access token from Azure AD there are plenty of ways of doing this in PowerShell. You could use a library like MSAL or ADAL (just google your favoured method) or use a library less approach which I've included with this script . Whatever way you do this you need to make sure that your application registration  https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-register-

How to test SMTP using Opportunistic TLS with Powershell and grab the public certificate a SMTP server is using

Most email services these day employ Opportunistic TLS when trying to send Messages which means that wherever possible the Messages will be encrypted rather then the plain text legacy of SMTP.  This method was defined in RFC 3207 "SMTP Service Extension for Secure SMTP over Transport Layer Security" and  there's a quite a good explanation of Opportunistic TLS on Wikipedia  https://en.wikipedia.org/wiki/Opportunistic_TLS .  This is used for both Server to Server (eg MTA to MTA) and Client to server (Eg a Message client like Outlook which acts as a MSA) the later being generally Authenticated. Basically it allows you to have a normal plain text SMTP conversation that is then upgraded to TLS using the STARTTLS verb. Not all servers will support this verb so if its not supported then a message is just sent as Plain text. TLS relies on PKI certificates and the administrative issue s that come around certificate management like expired certificates which is why I wrote th

The MailboxConcurrency limit and using Batching in the Microsoft Graph API

If your getting an error such as Application is over its MailboxConcurrency limit while using the Microsoft Graph API this post may help you understand why. Background   The Mailbox  concurrency limit when your using the Graph API is 4 as per https://docs.microsoft.com/en-us/graph/throttling#outlook-service-limits . This is evaluated for each app ID and mailbox combination so this means you can have different apps running under the same credentials and the poor behavior of one won't cause the other to be throttled. If you compared that to EWS you could have up to 27 concurrent connections but they are shared across all apps on a first come first served basis. Batching Batching in the Graph API is a way of combining multiple requests into a single HTTP request. Batching in the Exchange Mail API's EWS and MAPI has been around for a long time and its common, for email Apps to process large numbers of smaller items for a variety of reasons.  Batching in the Graph is limited to a m
All sample scripts and source code is provided by for illustrative purposes only. All examples are untested in different environments and therefore, I cannot guarantee or imply reliability, serviceability, or function of these programs.

All code contained herein is provided to you "AS IS" without any warranties of any kind. The implied warranties of non-infringement, merchantability and fitness for a particular purpose are expressly disclaimed.