Glen's Exchange and Office 365 Dev Blog

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

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

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

Mailbox analytics is something Microsoft have been working on for a number of years and its seems to be something that has received a little more effort in these pandemic times. If you have ever looked at the Non_IPM_Subtree of your mailbox you will see a lot of data being stored in their from various apps and substrate processes. A while back i wrote a ChangeDiscovery script to allow me to dump out quick what changes where happening in a Mailbox in a short time frame (eg i wanted to see what happened to all the items in a Mailbox when i performed a specific task). If you run this script with a slightly longer time-frame (eg looking over a day) it picks up all the Items that are being written and created for the Mailbox insights processes and other substrate processes. Most of these emails get written under the  Usually if I then wanted to look at these type of items I would use OutlookSpy or MFCMapi to browse the raw MAPI properties on items to see if they where of interest. Given...

One of the email UI features that I find the most useful in Outlook on the Web and Outlook mobile is the People favorites feature which saves having to do a search for historical email from particular high use contacts. Favorites is a feature that has evolved especially in Outlook on the web and Outlook mobile eg People/Persona favorites and category favorites. The way this is implemented in the Mailbox is interesting eg   People/Persona favorites get their own search folder under the favoritePersonas Folder in the Non_IPM_Subtree in a Mailbox eg As well as a configuration object under the  \ApplicationDataRoot\32d4b5e5-7d33-4e7f-b073-f8cffbbb47a1\outlookfavorites eg The configuration object is of interest as this tells as a lot about what type of favorites are being created and used in a Mailbox. It also can serve in a custom app if you want to reproduce the same type of favorites folder tree (you will need to use EWS for this as the Graph API is unfortunately hamstrung ...

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

MFA (Multi Factor Authentication) is great at making the Authentication process more secure in Exchange Online but can be challenging in Automation scenarios. I originally wrote this code for something that I wanted to run unattended on a RasberryPi that was running PowerShell that i wanted to use MFA on and where i wanted to avoid going down the path of using the 90 day RefreshToken/device code method and I also didn't want to use App Authentication via Certificates or Client Secrets. Interestingly while i was writing this post Microsoft just announced Certificate based Modern Auth in Exchange Online PowerShell  https://techcommunity.microsoft.com/t5/exchange-team-blog/modern-auth-and-unattended-scripts-in-exchange-online-powershell/ba-p/1497387   .  This article also links to the Secure App Model  https://docs.microsoft.com/en-us/powershell/partnercenter/multi-factor-auth?view=partnercenterps-3.0#exchange  which is the way Microsoft are recommending you handle...

This is a follow-on from my last post on  Modifying your EWS Managed API code to use Hybrid Modern Authentication against OnPrem Mailboxes  . If instead of the EWS Managed API you are using EWS Proxy Code (generated from the EWS WSDL) and you want to migrate it to using Modern Authentication for Office365 and/or Hybrid here's a method you can use using the MSAL Authentication library . Unlike the EWS Managed API the WSDL generated proxy classes and specifically the ExchangeServiceBinding class doesn't have any provision to use Token Credentials. One way of implementing this in .NET is to take advantage of  Polymorphism and create a new class that is derived from the ExchangeServiceBinding class and then override the method GetWebResponse from this class (which is actually derived from the SoapHttpClientProtocol class which contains the actual method we are going to override  https://docs.microsoft.com/en-us/dotnet/api/system.web.services.protocols.soap...

In this post I'm going to look at what you need to do in your EWS Managed API code to support using Hybrid Modern Authentication where previously you've been using Basic or Integrated Authentication (both of which are susceptible to password spray attacks). If you don't know what  Hybrid Modern Authentication   is put simply it brings to Exchange OnPrem email clients the security benefits of Modern Authentication offered by Azure AD to Office365 tenants. If your already using OAuth to connect to Office365 you have most of the work already done but you will still need logic to ensure you have the correct Audience set in your token when that code is used against an OnPrem Mailbox.  Prerequisites  You need to be using Hybrid Exchange or more specifically  Hybrid Office 365 tenant is configured in full hybrid configuration using Exchange Classic Hybrid Topology mode ref  https://docs.microsoft.com/en-us/exchange/clients/outlook-for-ios-and-android/use-hybr...

While the Search-Mailbox cmdlet is now depreciated in Exchange Online, OnPrem its still used a fair bit and also does still have some use in the cloud for specific tasks. I've been using it this week a fair bit for various testing tasks and one pain I found when doing a lot of repeated searches in logging mode is each time to have to go in, open the results message in the discovery search mailbox and download the attachment with the log file, unzip and open it in Excel. So I came up with a way of automating this in powershell which turned out to be pretty simple but effective. First off the only information you need to get the Results Message gets returned in the Target Folder property of the Search results eg.  The TargetFolder value tells you what folder in the discovery Search mailbox the results are stored in and the DateTime value that will be in the subject of the Results Message. So in EWS you can use FindFolder to Find that Folder (using a Split on "\" wh...

I've done some updating of my ExchangeContacts PowerShell module to support the following Modern Authentication in Office365 (distributing the ADAL dll with this module) Compiled and distributed the latest version of the EWS Managed API from GitHub with the module New cmdlet Export-EXCContacts that supports exporting all contacts in a Folder to a single VCF File New cmdlet Export-EXCContacts that supports exporting all contacts to a CSV file (this was already possible with the ExportFolder cmdlet but this is a slightly enhanced format) New cmldet Export-EXCRootContacts lets you export the Non_IPM Subtree folders that contain contacts. (Some of these are created by the Office365 substrate process) for example mycontacts, AllContacts, ContactSearch folders etc. Include dedup code based on Email Address in this cmdlet This is already supported but I wanted to show how you can export the Hidden Contacts Folder likes Recipient Cache, Gal and Organizational Contacts New cmdlet ...