Skip to main content

Posts

Showing posts from 2021

Sending a Message with a Large attachment using the Microsoft Graph and Powershell

Sending a message with a large attachment used to be the least worst option when it came to shipping data between people. In the Modern workplace where document and file sharing options are a lot better sending email with a large attachment can tends now to be the worst option especially when it comes to version control, expiration etc. However if you do find yourself with the need to send an email with large attachments (larger then 4MB) and you want to make use of the Microsft Graph API then it requires you use a different method from just sending the message in one post eg  https://docs.microsoft.com/en-us/graph/outlook-large-attachments?tabs=http This does make sending a Message a lot more complex eg if you have a Message less the 4MB you can just make one REST Post to send that message. If you have a large attachment you then have a multi step process eg Create a Draft message where you set all the other message property eg Subject,To,Body Take the MessageId(graph item id) returne

Sending a MimeMessage via the Microsoft Graph using the Graph SDK, MimeKit and MSAL

One of the new features added to the Microsoft Graph recently was the ability to create and send Mime Messages (you have been able to get Message as Mime for a while). This is useful in a number of different scenarios especially when trying to create a Message with inline Images which has historically been hard to do with both the Graph and EWS (if you don't use MIME). It also opens up using SMIME for encryption and a more easy migration path for sending using SMTP in some apps. MimeKit is a great open source library for parsing and creating MIME messages so it offers a really easy solution for tackling this issue. The current documentation on Send message via MIME lacks any real sample so I've put together a quick console app that use MSAL, MIME kit and the Graph SDK to send a Message via MIME. As the current Graph SDK also doesn't support sending via MIME either there is a workaround for this in the future my guess is this will be supported.

Migrating Exchange Web Services (EWS) Directory and Recipient resolution code to the Microsoft Graph

 One of the more complex things to migrate in EWS when migrating to the Graph API is any directory access code that uses one of the following EWS operations FindPeople ResolveName ExpandGroup (ExpandDL) or if your using OnPrem you maybe using System.DirectoryServices to do direct LDAP requests of Active Directory. With the Microsoft Graph API these Directory based mail operations don't exist, because you have full access to the underlying AzureAD, so in theory everything should be achievable without these type of operations. For the most part this is correct where is starts to get a little grayer is around this like Address Lists and Exchange recipient types mostly because the Graph doesn't expose the following underlying Active Directory properties msExchRecipientDisplayType msExchRecipientTypeDetails msExchRemoteRecipientType so this can be a limitation if your migrating from LDAP code and some FindPeople implementations if your searching based on AddressList. Microsoft Graph

Using Batching to improve the speed of Contact creation in the Microsoft Graph

There's been a few contact creation scripts popup recently for the Graph API like this as well as a few questions on the forums around this topic lately. None of these examples and questions are taking advantage of using batching in the Microsoft Graph which will give you a significant uplift in performance vs the single request method when creating larger numbers of items and also help you a little around throttling. I've added a new post to my Graph 101 binder  on GitHub that includes an example of doing a CSV Contact import using batching and Service Principal Authentication  https://github.com/gscales/Graph-Powershell-101-Binder/blob/master/Contacts/Batch%20Importing%20Contacts.md   If your interested in a EWS version that can use larger batches (eg 60-100 contacts per request) I've also include an example on GitHub for this  https://github.com/gscales/Powershell-Scripts/blob/master/Graph101/BatchContactCreationEWS.ps1

Using Out of Office / automaticRepliesSetting with the Microsoft Graph with Service Principal Authentication

Out of Office (or automaticRepliesSetting) can be used for a vast number of different applications. For example in this Teams In/Out board   With the Microsoft Graph API there are two ways that can be used to get the automaticRepliesSetting either via the Mailbox setting Endpoint eg https://docs.microsoft.com/en-us/graph/api/resources/automaticrepliessetting?view=graph-rest-1.0 Or you can use MailTips which was the method i used in the Teams Apps eg https://docs.microsoft.com/en-us/graph/api/user-getmailtips?view=graph-rest-1.0&tabs=http eg When it comes to setting the OOF you must use the Mailboxsettings endpoint What is better ? for getting the OOF settings on a large number of users getmailtips because you can request up to 100 users in one request while if your batching Mailboxsetting you can only have a max of 20 user in a single batch. Permission and Authentication  One consideration for the Mailboxsettings endpoint is there is no ability to use Delegate permissions to access

Microsoft Teams Call History Outlook/OWA Addin

One of the Microsoft Teams features that I like the least is call history, for a number of reasons firstly its quite limited only 30 days worth of data and only includes direct calls and not meetings (which are often just scheduled calls). So when it comes to actually answering a question (like the one I found myself asking last week) when did I last have a call or meeting with person X it can't be used to answer this question.  The other thing is having that information available in the context of Outlook/OWA is a lot more useful for me (anyway) then digging through anther client to find its doesn't answer the question anyway. However while the call history in Teams only goes back 30 days the Teams CDR (Call Data Records) which I covered in https://dev.to/gscales/accessing-microsoft-teams-summary-records-cdr-s-for-calls-and-meetings-using-exchange-web-services-3581 do go back as far as your mailbox folder retention period. So with a little work I can use Exchange Web Services

Using the Tag for external email messages received feature in the Microsoft Graph and Exchange Web Services

The "Tag for external email messages received" feature was introduced into Office365 recently to help people better to identify mail that comes from external sender vs internal sender see this for more info on this feature . What happens when you enable this feature is that for messages with External sender a new Mapi property is set on those messages eg For messages from internal senders the property doesn't appear to get set and if the feature isn't enabled in your tenant then you won't see this property either. You can negate the boolean value of the property which will turn off the external tag. Using it in the Microsoft Graph API If you want to use it in the Microsoft Graph API when you retrieve messages you can include this as a SingleValueExtendedProperties eg for Retrieving and filtering message you can use I've included this in my Get LastEmail 101 graph sample  if you want to try this in a real mailbox eg you can do  Get-LastEmail -InternalSender -M

Auditing Inbox rules (and looking for hidden rules) with EWS in OnPrem Exchange

 After the events of the last weeks around the latest zero day vulnerabilities in Exchange   and once you've finished cleaning up any back doors that may have been left on servers its a good idea to review some other less known but established ways bad actors may hide persistent access within Mailboxes. One of these are Inbox Rules (but Mail Flow rules could also be used) and a more advanced method is the hidden Inbox rule exploit that was first talked about  https://blog.compass-security.com/2018/09/hidden-inbox-rules-in-microsoft-exchange/  and I covered it in  https://gsexdev.blogspot.com/2019/05/audting-inbox-rules-with-ews-and-graph.html  and somebody else  https://mgreen27.github.io/posts/2019/06/09/O365HiddenRules.html  there are a number of tools and techniques around detecting these types of rule but are all focused more toward Office365 as that was where at the time this exploit was being mostly employed. In my post at the time I modified the Microsoft script https://gith

Using Shared Mailboxes in the Microsoft Graph API from PowerShell

I've created a few new Binder entries in GitHub for using Shared Mailboxes in the Graph API using PowerShell The Binder index is  https://gscales.github.io/Graph-Powershell-101-Binder/   The topics covered are Accessing a Shared Mailbox folder and its Items Sending an Email from a Shared Mailbox The script for these entries can be found  https://github.com/gscales/Powershell-Scripts/blob/master/Graph101/SharedMailboxOps.ps1
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.