Adam's Site on systems administration

Exchange Online is a service where you pay Microsoft a monthly subscription for them to host your organization’s mail. It is typically cost effective to purchase this subscription, because the entire office suite and other cloud services are usually bundled along with it. Generally speaking, it is cheaper to have this service than it is to run and maintain a datacenter.

With that said, I am writing this post to vent about how Exchange Online, in its current implementation, is not enterprise worthy. This is because there are many crippling flaws with Exchange Online, as it is coupled with Outlook. And these flaws are not happen-chance bugs, but rather massive design flaws akin to Catch 22.

For example, with an E3 license, you are allotted 100gb mailboxes, hosted with Exchange Online. The problem comes in when Outlook (2016, 64-bit) is coupled with this service. Outlook does not support 100gb OST files at all. The OST file is a cache that is used to make mail locally accessible over high latency or poor network connections. And don’t kid yourself, Exchange Online falls under the category of “high latency” and “poor connection.” Even if you are stationed in a heavily metropolitan area with a bleeding-edge FiOS connection, you will be utterly bottlenecked by Microsoft’s performance quotas. Therefore, being able to cache important mail locally is necessary to make use of Exchange Online. But as I said earlier, Outlook does not allow for 100gb OST caches. Whenever the OST is grown past a “certain size,” Outlook’s tendency to crash increases (no one really has a definite number, it is dependent upon many factors). The OST is also more likely to become corrupt.

Typically, with an in-house\on-prem datacenter, these problems and crashes are easily remedied by resetting the mail profile in Windows. Once this is done, mail flows and begins re-caching and re-indexing. With on-prem servers, Outlook is normally usable while this happens, so it’s not much more than a nuisance.

But with Exchange Online, the MAPI connection over internet is throttled such that Outlook is nothing more than a brick while it downloads, caches, and indexes your mail. It also seems that the servers that host the mailboxes are governed to limit performance. This means that it takes hours to complete a cache. And not just any hours. It takes many operational\business hours because it must take place under that particular user’s account, while they are signed in, while Outlook is on and running.

That is why Microsoft has a hard stop for the OST (of 50gb in size) to avoid crashes in the first place. Though, there is a registry key that can be used to take this limit off. https://support.microsoft.com/en-us/help/832925/how-to-configure-the-size-limit-for-both-pst-and-OST-files-in-outlook

If you do not keep the cache to well below that limit, you are going to have ample crashes, and then the slow agonizing process of rebuilding occurs. If your mailboxes surpass that 50gb+ limit, then the OST is likely to crash repeatedly.

In fact, because of the saas model of Office, I have noticed that during some of those monthly update cycles, the OST and\or the Index become corrupt for heavy users. And that is with the semiannual channel, which is the most deferred channel of updates allowed. The only way to defer these updates more than this, would be to manually manage them and shut auto updates off. But that in itself is like a full-time job.

What’s stupid about all of this is that the service claims to offer 100gb mailboxes, but you can’t actually use that much space because of this limit on the client-end and because of the performance limitations in the cloud.

When prodded for answers, Microsoft merely suggests that you limit the amount of locally cached mail to 12 months or less (or until the OST is within an acceptable size i.e. less than 20gb). The problem with this is that you are now at the mercy of Exchange Online’s performance, when you do searches. Because, searches are first performed locally through the (now minimized) cache, and then it goes off to the cloud to fetch the rest. In this model, only locally cached mail is fully indexed and is reasonably searchable. But for anything older than 12 months (or whatever the cache is set to) search results are sporadic, inconsistent, and incomplete. You could perform the same search twice in a row and end up with different results each time. Even if you were to use OWA, the searches performed there are very slow and at times unreliable.

It’s only when the entire mailbox is cached locally that you are able to perform fast and reliable searches, regardless of search scope or specificity. Furthermore, when searching online, your results are capped to 250 items which is a limit set by the service. Click here for the User Voice Complaint And this limit applies to the local client as well, if you do not cache all of your mail in Outlook.

This limit can only be lifted with a regkey, and it only works if you (once again) cache all of your mail locally. Which you can’t, if you are actually dealing with 50gb+ mailboxes.

https://www.slipstick.com/outlook/outlook-search-results-are-limited-to-250/

Another problem with Exchange Online is the fact that you cannot use Outlook in online mode. The performance limitations due to latency and enforced quotas renders online mode unusable. That is why in a VDI and multi user environment, I was relegated to using a 1 month cache for Outlook. And that cache was relocated to a dfs share. This is done using this regkey:

HKEY_CURRENT_USER\Software\Microsoft\Office\xx.0\Outlook
ForceOSTPath
\\dfs\share\XX.ost

That way on a floating pool, you don’t have to deal with duplicate caches on a pool of machines for each user and users won’t have to deal with waiting for their cache to download. Surprisingly, this implementation works without error in my environment. But, again, remote users are not working as intensively on the VDI platform as they do on their local systems.

So you lose functionality with this service. Kiosk type setups are out of the question.

Another problem is the 72 hour index reconciliation that happens and is scheduled, by default, in Outlook. I cannot find any documentation anywhere, as to the nature or implication of this feature. But it seems that every 72 hours, the index for mail is either rebuilt in its entirety, or is “reconciled” for some reason. Problem is that when this happens, it makes searches incomplete and unusable. I never had this problem with an on-prem datacenter before, so it must be related to the service and\or the size of the mailboxes allowed. This index reconciliation is such a crippling problem that it has to be turned off. We cannot afford to have 5 hours’ worth of search downtime scheduled every other day, during business hours mind you, while the users are at work. There are event ids 29, 30, and 31 in regards to this problem in the event viewer. https://support.microsoft.com/en-us/help/2769651/outlook-search-returns-no-matches-found

Index recon can be disabled by regkey, but I do not know what the long-term implications are. But it’s not as though there is a choice in the matter, as this maintenance task is causing more problems than it could ever prevent\resolve. Specifics listed here

Another problem with Exchange Online is the fact that you do not really know where your mailboxes are hosted. Microsoft automatically determines where they think it is best hosted. Their idea of best, as you can imagine, is probably defined by their own self-interested goals. They might position you far away, for the sake of their own load balancing strategies, and you may incur problems as a result. And they think that they can just sort of sweep these complaints under the rug by throwing the blame on your specific configuration or mail usage patterns.

In theory, if all goes well, you shouldn’t notice a difference with where it is hosted. This is the idea behind the “cloud,” after all. You are abstracted away from the underlying infrastructure, and you have to trust your service provider to take care of you.

Still, it is always better to have your data hosted as close to you as possible, to limit performance problems. Also, not every datacenter is created equal. Yes, they do standardize their equipment and procedures, but I would rather have my mail hosted in Washington or San Francisco, rather than in Iowa. Because it is probably better managed. These centers could be better staffed, better run, more likely to have newer\faster equipment. Who knows.

You can pull information about where a mailbox is stored by first remoting into Exchange Online:

$UserCredential = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell-liveid?DelegatedOrg=<customer tenant domain name> -Credential $UserCredential -Authentication Basic -AllowRedirection
Import-PSSession $Session

And then Get-MailboxStatistics will give you many of the attributes for that particular mailbox, like the server and database in use.

This gets into another issue. If you are troubleshooting a mailbox and would like to repair corrupt mail items, you can no longer do so once on the cloud. The New-MailboxRepairRequest command only applies to on-prem Exchange 2016 servers. The only way that I am aware of to have a mailbox checked for problems on the cloud, is to move the mailbox to another datacenter\location. Whenever a mailbox is moved, it is automatically checked for problems. This could also probably be done by exporting back on-prem if you have a hyrbid setup, but it’s better to just move between datacenters in the cloud.

When you run the Get-MailboxStatistics command and look at the servername, the first few letters of the name correspond to the datacenter where that server resides. For example, “BL” refers to one of their datacenters in Virginia. Here is a key with that list of names to datacenters:

$Datacenter = @{}
$Datacenter["CP"]=@("LAM","Brazil")
$Datacenter["GR"]=@("LAM","Brazil")
$Datacenter["HK"]=@("APC","Hong Kong")
$Datacenter["SI"]=@("APC","Singapore")
$Datacenter["SG"]=@("APC","Singapore")
$Datacenter["KA"]=@("JPN","Japan")
$Datacenter["OS"]=@("JPN","Japan")
$Datacenter["TY"]=@("JPN","Japan")
$Datacenter["AM"]=@("EUR","Amsterdam, Netherlands")
$Datacenter["DB"]=@("EUR","Dublin, Ireland")
$Datacenter["HE"]=@("EUR","Helsinki, Finland")
$Datacenter["VI"]=@("EUR","Vienna, Austria")
$Datacenter["BL"]=@("NAM","Virginia, USA")
$Datacenter["SN"]=@("NAM","San Antonio, Texas, USA")
$Datacenter["BN"]=@("NAM","Virginia, USA")
$Datacenter["DM"]=@("NAM","Des Moines, Iowa, USA")
$Datacenter["BY"]=@("NAM","San Francisco, California, USA")
$Datacenter["CY"]=@("NAM","Cheyenne, Wyoming, USA")
$Datacenter["CO"]=@("NAM","Quincy, Washington, USA")
$Datacenter["MW"]=@("NAM","Quincy, Washington, USA")
$Datacenter["CH"]=@("NAM","Chicago, Illinois, USA")
$Datacenter["ME"]=@("APC","Melbourne, Victoria, Australia")
$Datacenter["SY"]=@("APC","Sydney, New South Wales, Australia")
$Datacenter["KL"]=@("APC","Kuala Lumpur, Malaysia")
$Datacenter["PS"]=@("APC","Busan, South Korea")
$Datacenter["YQ"]=@("CAN","Montreal, Quebec, Canada")
$Datacenter["YT"]=@("CAN","Toronto, Ontario, Canada")
$Datacenter["MM"]=@("GBR","Durham, England")
$Datacenter["LO"]=@("GBR","London, England")

There is a fantastic script written by, Joe Palarchio that will give you a generic report of the number of mailboxes, and their locations. To give you an idea of how fragmented your services really are. You can find his post here: https://blogs.perficient.com/microsoft/2016/03/office-365-script-to-determine-exchange-online-mailbox-location/

My only critique with Joe’s script is the fact that he references Get-Mailbox to determine the servername. I notice that the servername property in Get-Mailbox is not always accurate. Get-MailboxStatistics tends to be more up to date. Because the Get-Mailbox servername is rarely updated, except for “major changes” as per this article.

That is why the script I use references the servername property from Get-MailboxStatistics instead.

If you are having problems with a mailbox, find where the mailbox is located, and if it happens to be far away, then perform a move. On that move, the mailbox will be checked for errors and corruption. So that should kill two birds with one stone.

This is done by using the New-MoveRequest cmdlet. Example:

New-MoveRequest -Identity User@Domain.tld

The main problem with this, however,  is that you are at the mercy of Microsoft’s datacenter load balancing scheme, to pick the best location on your behalf. So, it has the potential of being hit or miss. There is a “targetdatabase” parameter that could be specified with this command. When I first saw this, I immediately thought of how useless it would be for O365 to O365 moves, seeing that we do not have a full list of destination servers\databases. Still, the documentation for this parameter suggests that it supports Exchange Online and On-prem installations.

So, I grabbed a known database from one of my other mailboxes that happened to be stationed in the target datacenter of choice. I took that database name and specified it in the cmdlet and it failed. So, I guess the “targetdatabase” option only applies to on-prem to cloud or vice versa movements. Cloud to Cloud traversals is done by solely specifying the identity of the mailbox and relying on Exchange Online’s decision making.

Anyways, once you kick off a generic New-MoveRequest user@domain.tld command, you ought to check the target server that Microsoft picks for you, so that it is close enough for your taste. This is done by running the Get-MoveRequestStatistics cmdlet. Like so,

Get-MoveRequestStatistics -Identity User@domain.tld | select sourceserver,targetserver,percentcomplete

(Look up the targetserver’s location via the key mentioned earlier)

Another problem is the sheer number of items allowed per folder, in Outlook. Outlook\Exchange has a limit on the number of items that can exist per folder. Not necessarily the size of the folder, but that actual\nominal number of items.  There is a limit of 100,000 items per folder in Outlook 2016. https://support.microsoft.com/en-us/help/2768656/outlook-performance-issues-when-there-are-too-many-items-or-folders-in  Now, it is ambiguous as to whether the count of items includes items in subfolders, or just at the root of a particular folder; and whether we should count “inbox” as a folder, since that would effectively limit the amount of mail you could have in total. To further confuse matters, we have 1,000,000 items set as a limit for “folders,” as per the “365” service. https://technet.microsoft.com/en-us/library/exchange-online-limits.aspx?f=255&MSPPError=-2147217396 I guess that the 100k limit is in regard to the number of items cached locally in Outlook, otherwise it doesn’t make any sense. So, I guess this nominal count is also a function\consequence of the size limit for the OST.

One way to make sure this “problem” isn’t an excuse for Microsoft to weasel out of providing you service, is to have large mailbox users break up their folders into other folders. This will reduce the number of items in each folder. This is also helpful in dealing with the 250 item return limit talked about earlier. When messages are organized by year, for example, that limits the scope of a search and increases the probability that a desired item is returned within that 250 item cap. So this modification kills another two birds with one stone.

You can run Get-MailboxFolderStatistics to recursively search mailbox folders and view the item count. Sample script provided later on.

Ultimately, Microsoft’s answer to all of these design flaws is to use archiving. But this solution defeats the purpose of purchasing a 100gb mailbox subscription in the first place. You pay for a service, they should be able to deliver. Furthermore, there are a whole host of other logistical problems with archives that I do not want to get into here.

Another side complaint I have is in regard to message tracking from the portal. If you are trying to pull logs on what happened to service during a period of time, or just want to track a particular message, you have seven days to get instant results. If the message in question is older than seven days, you have to submit a pre-written query via the portal and wait in a queue for it to be processed. Yes, a queue… To perform a query… And it can take upwards of 48 hours before it is processed to get results. For mission critical message tracking, this is unacceptable. I just recently had to perform an advanced message trace on a delayed message delivery. And Office 365’s message tracing is woefully vague and useless. Luckily I have access to a third party cloud filtering service that has much better message tracking.

It is clear that the 100gb mailbox offer is a bogus selling point figure. While it may be technically possible to literally (and merely) “store” that much mail on their service, it is obvious that they cannot truly deliver on what’s promised. Exchange Online is an economy service, like public transportation. You get poor service, poor performance, and terrible support. You get what you pay for.

Anyways, here is a script I wrote for troubleshooting mailboxes hosted on Exchange Online. It will scrape mailbox statistics from O365 and present them to you in a meaningful way. It displays the mailbox size, item counts, the user, the user’s office location, and the datacenter used for that mailbox. At the end, it will also list all of the mailbox folders in Exchange that have exceeded the 100k item limit. You can use this data to troubleshoot service problems. This will prompt for O365 credentials, what you provide will be used to connect to Exchange Online to run this report, it will also be used to send the email for the report. You need https access to outlook.com and port 587 for the office365 smtp relay. This will most likely already be the case for you. But that last requirement can be bypassed by using your own smtp relay of choice. The script requires 1 modification, and that is to edit the to and from addresses, to send the report. You can do that on lines 70 and 71.

$UserCredential = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection
Import-PSSession $Session

$Datacenter = @{}
$Datacenter["CP"]=@("LAM","Brazil")
$Datacenter["GR"]=@("LAM","Brazil")
$Datacenter["HK"]=@("APC","Hong Kong")
$Datacenter["SI"]=@("APC","Singapore")
$Datacenter["SG"]=@("APC","Singapore")
$Datacenter["KA"]=@("JPN","Japan")
$Datacenter["OS"]=@("JPN","Japan")
$Datacenter["TY"]=@("JPN","Japan")
$Datacenter["AM"]=@("EUR","Amsterdam, Netherlands")
$Datacenter["DB"]=@("EUR","Dublin, Ireland")
$Datacenter["HE"]=@("EUR","Helsinki, Finland")
$Datacenter["VI"]=@("EUR","Vienna, Austria")
$Datacenter["BL"]=@("NAM","Virginia, USA")
$Datacenter["SN"]=@("NAM","San Antonio, Texas, USA")
$Datacenter["BN"]=@("NAM","Virginia, USA")
$Datacenter["DM"]=@("NAM","Des Moines, Iowa, USA")
$Datacenter["BY"]=@("NAM","San Francisco, California, USA")
$Datacenter["CY"]=@("NAM","Cheyenne, Wyoming, USA")
$Datacenter["CO"]=@("NAM","Quincy, Washington, USA")
$Datacenter["MW"]=@("NAM","Quincy, Washington, USA")
$Datacenter["CH"]=@("NAM","Chicago, Illinois, USA")
$Datacenter["ME"]=@("APC","Melbourne, Victoria, Australia")
$Datacenter["SY"]=@("APC","Sydney, New South Wales, Australia")
$Datacenter["KL"]=@("APC","Kuala Lumpur, Malaysia")
$Datacenter["PS"]=@("APC","Busan, South Korea")
$Datacenter["YQ"]=@("CAN","Montreal, Quebec, Canada")
$Datacenter["YT"]=@("CAN","Toronto, Ontario, Canada")
$Datacenter["MM"]=@("GBR","Durham, England")
$Datacenter["LO"]=@("GBR","London, England")

 $csvreport = "$env:TEMP\MbxStatistics.csv"
 $AllMailBoxes = Get-Mailbox
 $AllMailBoxStatistics = $AllMailBoxes | Get-MailboxStatistics
 
 $ItemLimit = @()
 foreach ($mboxstat in ($AllMailBoxStatistics | where {$_.ItemCount -gt 100000})) {
  $ItemLimit += $AllMailBoxes | where {$_.name -match $mboxstat.displayname} | Get-MailboxFolderStatistics | where {$_.itemsinfolder -gt 100000}}

 $csvreportTEMP = $AllMailBoxStatistics | Select-Object DisplayName, Identity, ItemCount, TotalItemSize, LastLogonTime, servername, databasename | Sort-Object Totalitemsize -Descending 
 $regex = [regex] "(?<=\().*(?=\))"

 foreach ($Mbox in $AllMailBoxes) {
  $csvreportTEMP -match $Mbox | Add-Member -MemberType NoteProperty -Force -Name "DataCenterLocation" -Value ($Datacenter.item(($csvreportTEMP -match $Mbox).ServerName.SubString(0,2))[1])
  $csvreportTEMP -match $Mbox | Add-Member -MemberType NoteProperty -force -Name "OfficeLocation" -Value $Mbox.Office
  $sizeingb = ($regex.match(($csvreportTEMP -match $Mbox | foreach {$_.totalitemsize.value.ToString()}))).Value.Split(" ")[0].Replace(",","")/1gb
  $sizeingb = [math]::Round($sizeingb,4)
  $csvreportTEMP -match $Mbox | Add-Member -MemberType NoteProperty -Force -Name "TotalItemSizeinGB" -Value $sizeingb}

$csvreportTEMP | Sort-Object TotalItemSizeinGB -Descending | Export-Csv -Path $csvreport -Force


#Email Instructions
$BodyofEmail = "
<br>
Here is the report (More data\columns available in the attached csv file):
$($csvreportTEMP | Sort-Object TotalItemSizeinGB -Descending | ConvertTo-Html -Property displayname, totalitemsize, servername, datacenterlocation, officelocation)
<br>
<br>
<br>
Here is a list of folders in Exchange that are pushing the 100k item limit, per folder:
$($ItemLimit | where{$_.Name -ne "Inbox"} | Sort-Object itemsinfolder -Descending | ConvertTo-Html -property Identity,Name,FolderPath,foldersize,Itemsinfolder -)"


$Subject = "Exchange Online Report"
$ToAddress = "##@####.com"
$FromAddress = "##@####.com"

Send-MailMessage -To $ToAddress -From $FromAddress -Body $BodyofEmail  -SmtpServer smtp.office365.com -Credential $UserCredential -Subject $Subject -BodyAsHtml -Attachments $csvreport

#Clean up
Get-PSSession | Remove-PSSession
Remove-Item $csvreport

This report took 18 minutes to run for my modestly sized query (couple hundred mailboxes), so this is something that you run and let process in the background, until you get that emailed report.

The last workaround I want to mention is an old configuration, where only headers will be downloaded. You can set Outlook to header-only mode. This is useful, if you intend on caching the entire mailbox for searchability. The trade off is that day-to-day use is a bit annoying, because each message has to be opened in order to be marked as read. They will not automatically be marked as read, if selected in the preview pane. To get around that hassle, I wrote a VSTO add-in in C# that would download all new messages as full items upon click; while leaving the rest of the mailbox in header-only mode. So long as you do not intend on performing deep, specific searches, this should work to get any message by date\to\from and any other metadata (anything contained in the header). This turned 70gb mailboxes down to 4gb in OST size.

This could be a good work around to most of these problems. I am not an expert in C# so if there are ways to improve on the code, please let me know.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Xml.Linq;
using Outlook = Microsoft.Office.Interop.Outlook;
using Office = Microsoft.Office.Core;

namespace DownloadFullItems
{
    public partial class ThisAddIn
    {
        private Outlook.NameSpace outlookNameSpace;
        private Outlook.MAPIFolder inbox;
        private Outlook.Items items;

        private void ThisAddIn_Startup(object sender, System.EventArgs e)
        {
            outlookNameSpace = this.Application.GetNamespace("MAPI");
            inbox = outlookNameSpace.GetDefaultFolder(
                    Microsoft.Office.Interop.Outlook.
                    OlDefaultFolders.olFolderInbox);

            items = inbox.Items;
            items.ItemAdd +=
                new Outlook.ItemsEvents_ItemAddEventHandler(items_ItemAdd);
        }

        void items_ItemAdd(object Item)
        {
            Outlook.MailItem mail = (Outlook.MailItem)Item;
            if (Item != null)
            {
                if (mail.DownloadState == Outlook.OlDownloadState.olHeaderOnly && mail.ReceivedTime.ToString("yyyyMMdd") == DateTime.Now.Date.ToString("yyyyMMdd"))
                {
                    mail.MarkForDownload = Outlook.OlRemoteStatus.olMarkedForDownload;
                    mail.Save();
                }
            }
        }

            private void ThisAddIn_Shutdown(object sender, System.EventArgs e)
        {
            // Note: Outlook no longer raises this event. If you have code that 
            //    must run when Outlook shuts down, see https://go.microsoft.com/fwlink/?LinkId=506785
        }

        #region VSTO generated code

        /// <summary>
        /// Required method for Designer support - do not modify
        /// the contents of this method with the code editor.
        /// </summary>
        private void InternalStartup()
        {
            this.Startup += new System.EventHandler(ThisAddIn_Startup);
            this.Shutdown += new System.EventHandler(ThisAddIn_Shutdown);
        }
        
        #endregion
    }
}

In conclusion, to make this service work as well as possible with 50gb+ mailboxes, I will rehash all of the workarounds below:

1. Relocate the mailbox to the nearest datacenter\Repair.
2. Cache the most mail you can, such that you are comfortably under the 50gb OST limit.
3. Schedule OST compaction, off hours (Not sure if possible to do).
4. Turn off index reconciliation.
5.  Disable OST recreation on file upgrade. Specifics here
6. Defer feature updates, perhaps manually manage the monthly security updates for office.
7. Make sure that offline files\redirection do not affect the OST cache.
8. Break up the mailbox by year (or some other organization scheme) to keep the 100k item limit in check, and to limit the scope of searches for better results.
9. Remove any and all third-party add-ins.
10. Enable “Download Header” mode in Outlook.

That should give you the best results, as you attempt to actually make use of their garbage service. Still, if mail is the bread and butter of your firm, you will not like using Exchange Online. It is slow, fickle, unreliable, and Microsoft really doesn’t care. You cannot even open a professional paid service ticket in regard. They will close your ticket and redirect you to some outfit in India, where their go to solution is to blast the OST.

In short, Exchange Online is not a premium service. It is only a decent and cost-effective solution if you do not plan on actually using the amount of space they claim to offer. I maintain that this service makes sense for new\small businesses only. And only if mail does not play a critical role in business correspondence. With time, the service may improve. And I think that this is the ultimate idea. These cloud services obfuscate away the infrastructure so that you don’t have to think about it. By the time early adopters begin pushing that 100gb limit, it would most likely be the case that the service would have improved to easily handle that amount of data. But for today, and for firms that heavily rely on mail for day to day operations, I would stray away from this service if possible. It really isn’t any better than an in house server + a SQL-based auto archiving solution.

Script(s) Mentioned in This Post:

Exchange Online Report (https://adameyob.com/scripts/exchange-online-report/)

Download Full Items – Outlook 2016 (https://adameyob.com/scripts/auto-download-full-items-vsto-add-in-for-outlook-2016/)