Glen's Exchange and Office 365 Dev Blog

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

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.

 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

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

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

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

 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

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