Glen's Exchange and Office 365 Dev Blog

With the full depreciation of Basic Authentication around the corner I've put together a Github doc to show one implementation of using MSAL with the EWS Managed API that supports both Hybrid Modern Authentication and token caching and refresh. It can be found  https://github.com/gscales/EWS-BasicToOAuth-Info/blob/main/EWA%20Managed%20API%20MASL%20Token%20Refresh.md

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

Mailbox Change discovery is the process of looking at any folders or items that are new or have been modified recently in a Mailbox. Its useful in a number of different ways including (but not limited to) Looking at what objects a third party Addin is creating or modifying in your mailbox Help to work out which FAI (Folder Associated Item) is being modified when changes are made to the configuration in Outlook or Outlook on the Web (this can be useful if you then want to automate those changes in your own scripts) Fixing client issues caused by corrupt or bad items (eg if you've ever used MFCMapi to delete and Item that's causing a particular client function not to work correctly) Getting an understanding of how the backend scaffolding of new features work in Outlook on the Web (eg looking at what the substrate Is doing in Office365)  If you have ever looked recently at the Non_IPM Root folder of any Office365 Mailbox you can see by the large number of folders that are...

Zero-hour auto purge is one of the features of Office365 that will detect malicious and Spam emails and move them to the Junk email folder for any email that has breached the first level defences and has been delivered to users mailboxes. There is a good description of how it works here but basically when the service learns a particular message was malicious/spam it can retrospectively detect and eliminate/move any simular messages that arrived previously and weren't detected. This is a good and much need feature as no AntiSpam or Malware solution is perfect (no matter what the vendor say) so there will always be the case where thing slip through. But this very fact is what causes an exposure point where the potentially malicious email sits in the Inbox of end user up until the time its gets zapped. What I wanted to present in this post is a few ways you can measure the amount of the time you may have been vulnerable for and show some methods you can use to look more at message...

A little background The LAPFID property is an extended property that gets set on an Exchange Store Item when its deleted (any type of delete soft or hard) that is the enabler for the original folder item recovery feature that rolled out to both Exchange Online and Exchange OnPrem (2016) last year. If you where to look at this property in a MAPI editor it would look like the following To understand what that property Id value represents you need to first understand a little bit more about the Folder EntryId format (PR_EntryId) that exchange uses which is documented in this Exchange Protocol Document https://msdn.microsoft.com/en-us/library/ee217297(v=exchg.80).aspx . A different visual representation of this with the individual components highlighted would look something like this Hopefully from this you can see that the LAPFID is comprised of the DatabaseGUID and GlobalCounter constituents of the FolderEntryId. To make sense of the  LAPFID you need to resolve it back ...

Microsoft recently posted an update that will affect those people who use EWS in applications and script against Office365  https://blogs.technet.microsoft.com/exchange/2018/07/03/upcoming-changes-to-exchange-web-services-ews-api-for-office-365   While 2020 is a few years away what this means is that if you are using Basic Authentication in your EWS scripts or applications that on the 13th October 2020 your app will stop working. Given the amount of time you have and the changes required to support oAuth nobody should really be caught out by this but procrastination and people not understanding legacy applications will mean I'm sure this date won't pass without any infamy. Within PowerShell scripts you have two options to generate the oAuth tokens you need to keep you script working. One is to use a dependency library like ADAL to do it which Ingo posted a really good write up for https://ingogegenwarth.wordpress.com/2018/08/02/ews-and-oauth the other is just create some ...

Folder Item numbers, size's and Attachment Item Numbers, types and sizes are one of the Mailbox statistics that is useful when your trying to look at how and why a mailbox is growing or why your mailbox performance might be declining if you have a large number of folder items. With the recent increases in Mailbox size quotas  in Office365 it can be easy to become quite indifferent to how quickly your mailbox might be growing. For example if you have 100GB quota the lazy mindset (which I admit to being a part of) can be to just keep everything you get via mail (or stack it and rack it). If your users are not able to take advantage of cloudy attachments (or the users refuse to change their use habits) the nature of expanding file sizes means a sharper growth curve for Folder Items and Attachments. The traditional way of tracking Mailbox sizes is to use Get-MailboxStatistics and Get-MailboxFolderStatistics for which there are many good scripts around that give a good overview of wha...