New templated email policies


If you dip into your Microsoft 365 Security and Compliance Center, then into Threat Management and then into Policy as shown above you might some new Templated policies.


This will allow to select from two ‘best practices’ policies for your email protection from Microsoft. There is a standard and a Strict protection option.

You’ll find details about these here:

Preset security policies in EOP and Office 365 ATP

and if you want to know the low level settings that use you can find that here:

Recommended settings for EOP and Office 365 ATP

At the moment they are not enabled by default, but I can see the day when at the least the Standard template will be applied to all new tenants.

Of course, these are just a starting point for securing your email environment in but I certainly recommend that you do start with these templates because they apply a lot of best practices quickly and easily. They also configure not just Exchange Online but also Office 365 Advanced Threat protection (ATP) if that is part of the tenant.

Get-Formatdata issues when connecting to Exchange Online with PowerShell

*** Update 10 July 2020. This is a back end service issue that Microsoft is working on to resolve. See the following for more details –


To connect to Exchange Online with PowerShell you simply type a command like:


as shown above. This “should” work with Exchange Online PowerShell V2. However, as you can also see from the above screen shot this generates the following error on a number of tenants:

Import-PSSession : Data returned by the remote Get-FormatData command is not in the expected format

This therefore, prevents you from connecting to Exchange Online via PowerShell.

Interestingly, you get the same issue if you use the older method of connecting to Exchange Online via PowerShell (aka V1) to those same specific tenants. It is also independent of the device you use to connect, updates, etc. It seems to be tied to only a limited number of tenants for some reason.


The fix for now is to specify the –delegatedorganization parameter with the full user identity. When you do that, to exactly the same tenant, you can gain access as shown above without an error.

So, if you need access use:

connect-exchangeonline –delegatedorganization <tenantname>

and you should be able to gain access. The problem is that this is ok for interactive sessions but if you already have bulk automated scripted in place that don’t use this then it is painful to start changing these just to accommodate a ‘limited’ number of affected tenants.

I am chasing down some leads to try to determine a reason for this and hopefully find a resolution soon.

Configure new Edge to allow Exchange PowerShell MFA module download

One of the challenges with MFA and PowerShell is that you need to basically go into the Exchange management console and download a special PowerShell module that supports MFA. The need for that MFA module when connecting to Exchange Online with PowerShell is largely being negated by using the Exchange Online PowerShell V2 module (yeah). However, if you want to connect to the Security and Compliance center online with PowerShell and MFA you are still going to need to install this special module MFA from the Exchange Admin center in the portal (damm).


To do this, you’ll need to navigate to the Exchange admin center as shown above and select Hybrid from the items on the left. you’ll then need to select the lower option that is then displayed on the right hand side, which allows you to download the special MFA PowerShell module.

That should commence an automated download for you. This automated download “should” work in both the older Internet Explorer and the new Edge (chromium based) browser.


That download process should look something like what is shown above. However, if for some reason you can’t get it working with the new Edge (chromium based) browser navigate to:



and Enable the ClickOnce Support option as shown above, if not already enabled. Most of the time it is set as Default, which you will need to change to allow the download to commence.

The browser will need to reload, but after that you should able to run the file in the Edge (chromium based) browser to get the Exchange Online MFA module installed on your local machine.

Exchange Online mailbox check script update

I have just updated another of the free PowerShell scripts I provide on Github. This time o365-mx-check.ps1 has been given an update. You will find it here:

1. Prior to running the script you will have needed to install the Exchange Online PowerShell module. To set up your PowerShell environment I suggest you check out:

2. Connect to Exchange Online with PowerShell. For that I recommend you use my script:

That should result in you being connected to Exchange Online PowerShell as shown above.

Once you have your PowerShell environment setup, you simply run the o365-mx-check.ps1 script at the PowerShell prompt.


After checking that the Exchange Online PowerShell module is loaded and connected, the script will loop through all the mailboxes in your tenant.


For each mailbox it will check and display a number of settings as shown above including:

  • Users Display name and principal name
  • The primary outbound email address the mailbox uses
  • When the mailbox was created
  • Whether auditing is enabled for the mailbox
  • What the maximum age limit of audit log entries for the mailbox
  • Deleted items retention period
  • If Litigation Hold is enabled
  • If mailbox archiving is enabled
  • The maximum message send size
  • The maximum message receive size
  • If POP3 is enabled for the mailbox
  • If IMAP is enabled for the mailbox

Items that are not best practices will be highlighted in red for your attention as shown above.

By default, these results will only display on the screen, however if you specify the optional –CSV parameter when you run the script like:

.\o365-mx-alert –csv

A CSV file with the output will be created in the parent directory.


You will see the name of the CSV created at the end of the script as shown above.


Each CSV file is timestamped to ensure that a unique file will be created each time the script is run.

A log file, o365-mx-alert.txt is also created in the parent directory as well on each run.


The log file will be overwritten each time the script is run.

Thus, the o365-mx-check.ps1 script has 1 optional parameter, that can be used:

-csv = output all logs for period to a CSV file in the parent directory. A new CSV file is created for each script execution

The script will also produce a log file (o365-mx-check.txt) in the parent directory, that is overwritten on the each run of the script.

You will find this script and all my publicly available scripts at:

Don’t forget to check back there regularly for updates. Also, if you have any feedback or suggestion on this script or what you’d like to see me create, please let me know. I also maintain a large array of additional scripts via a paid subscription. More details of that can be found at

Need to Know podcast–Episode 241

FAQ podcasts are shorter and more focused on a particular topic. In this episode I’ll talk about the importance of checking your inbound Exchange Online policies to improve security.

This episode was recorded using Microsoft Teams and produced with Camtasia 2019

Take a listen and let us know what you think –

You can listen directly to this episode at:

Subscribe via iTunes at:

The podcast is also available on Stitcher at:

Don’t forget to give the show a rating as well as send us any feedback or suggestions you may have for the show.


CIAOPS Patron Community

Configure SPAM policies in EOP



Microsoft 365 mailbox reporting issue


If I look at my mailbox I see a total of 64,382 items in the deleted items as shown above.


If I then look at my Online Archive I see 44,024 items in the archived deleted item as shown.

This means I have 64,382 + 44,024 = 108,406 items in total in my deleted items.


If I however run the Exchange Online PowerShell module v2 command as shown above,


it only reports 11,865 items??


If I look at the Mailbox usage statistics in the Microsoft 365 Admin center reports for 7 days I see 11,637 as the deleted item amount.


If I look at the Mailbox statistics in the Microsoft 365 Admin center reports for 30 days I see 11,637 as the deleted item amount. The same number as for 7 days.



Both 90 and 180 day options reveal the same results, Deleted Item Count = 11,637? Why?

Now compare this to Email activity over 7, 30, 90 and 180 days.





The numbers vary based on the period as you see above. This is what I would expect to also see for Mailbox usage numbers.

If you have a look at:

Microsoft 365 Reports in the admin center – Mailbox usage

It says:

Deleted Item Count refers to the total number of deleted items in the mailbox.

but that is only reporting 11,637 items not the expected 64,382. Also, changing the period of those reports doesn’t change the number of Deleted Items. I would have thought that if the figures shown were total items during that period, they would vary as I changed the period. But they don’t. I would expect a small figure for Deleted Item for 7 days and a larger figure for 180 days say. I wouldn’t expect the same figure for 7, 30, 90 and 180 days!

So there must be something I’m missing here with these numbers? Anyone care to enlighten me?

Making PowerShell automation easier with the Microsoft Graph

About 2 years ago I released a free PowerShell script that allowed you to check for email forwards on mailboxes in a Microsoft 365 environment. I wrote about that script here:

This is still the most comprehensive method in my books for checking for all the various type of forwards on a mailbox and I recommend you continue to use the script which you’ll find freely available at:

As good as that script is, there are still challenges for many people actually using it I have found. This mainly revolves around getting an appropriate PowerShell environment running, installing the Exchange Online PowerShell modules, connecting to Exchange Online with PowerShell and so on. I have detailed how to do all that over the period here but I still find that many struggle to make use of the PowerShell script.

So a new approach is in order. In short, I have a new version of this script that is a single EXE file you can download and use here:

It is important to note that this script does not make any changes to users or their mailboxes, it just reads and reports their mailbox rules using the Microsoft Graph. As yet, it can’t check more exotic things like direct mailbox forwarding or sweep rules, but you gotta start somewhere!

Let me show you how it works.


You’ll need a PC that is running a current version of PowerShell. A Windows 10 PC will work fine. You should also have the AzureAD PowerShell module loaded prior in your environment. To do that, all you need to do is run an elevated PowerShell console and type install-azuread. However, hopefully most people already have this loaded.

Download my new file from:

and copy it anywhere on your machine as shown above. Double click to run the file.


You should now see a window like shown above.

The program will first check for the Azure AD PowerShell module. It will then prompt you to log into your tenant of choice.


You’ll go through your normal login process to a tenant as shown.


Including using MFA if required.


Once logged into the tenant, a new Azure AD application will be created in the tenant with a unique name as shown above. The name in this case is CIAOPS-20200415232309. With the app created in the tenant, appropriate permission are added to that app to allow it to do things like read the list of users, their mailboxes, etc.

After this app has been created and permissions applied to it to allow it to do its work, those changes need to be consented or approved by someone (typically the same user that initially logged into the tenant). Unfortunately, from what I can see, consent can only be managed via the browser. With that in mind, the required URL is copied to the clipboard and you are prompted whether you wish to open the default browser to complete this process. Copying the consent URL to the clipboard allows you to manually paste it to your browser session of choice. This is handy if you are working in multiple tenants currently.


You’ll now be prompted to login to the tenant again, but this time in a browser.


You should then see a list of requested permissions as shown above that you’ll need to accept for this process to complete.


If you look at the top of the dialog to see what is requesting permission you should see the name of the Azure AD application as noted previously. Here again that is CIAOPS-20200415232309.


Also note that there is only one write permissions requested, the majority are only read. Where do these permission come from? To use the Microsoft Graph, for example, to list the email folders for a user you use the command here:

in which you’ll see to do this you need the permissions:

Mail.ReadBasic.All, Mail.Read, Mail.ReadWrite

I have tried to keep the rights requires as basic as possible but I am using what the Graph provides.

You’ll see that it needs a number of permissions to accomplish this. Basically, I have automated the process I detailed how to do manually before here:


After you Accept the permissions, you should be return to the home page of your tenant as shown. If for reason the consent page doesn’t appear or something else strange happens, just paste in the URL and try again. Sometimes web request don’t always work.


If you now return to the program you’ll see that it is prompting you to confirm that you have completed the consent stage.  Type Y and press ENTER to continue.


Because the web consent step can take a short while to complete I now wait 10 seconds, just in case, for this to complete.


The program will continue, getting all the information it needs and then starting to report on user mailboxes as shown above.


Once all mailboxes have been checked the Azure AD application created to facilitate this process (here CIAOPS-20200415232309) is deleted from your tenant to leave zero touch.

If you then press any key, the program will complete.


If you now look in the source directory you will see two new text files as shown above.


The first file, graph-mdx-rules.txt is basically a debugging log file that records what happens during the initialisation phase of the program.


The file mbx-rules.txt is basically a copy of the results.

Note, both of these file get overwritten each time the program runs.

Hopefully, this new program makes it much easier to get the information your need. However, because much is automated and simplified, some may be concerned as to what is actually happening behind the scenes. Well, thanks to the wonders of Azure AD you can easily see.


To review the whole process, open you Azure portal and navigate to Azure Active Directory and then Audit logs as you see above.


In there you should find an entry that corresponds to the Azure AD application being added as shown above. Note the name corresponds to the one details previously, here CIAOPS-20200415232309.


You should then see entries where permissions have been added to Azure AD application as shown above.


A bit further along, you’ll see where consent was granted to the Azure AD application as shown above.


Lastly, you’ll also see where that Azure AD application is completely deleted from the environment leaving no fingerprint.

This is a new approach to automation that I believe will work well. There is still a lot of work that needs to be done and there are still some limitations but hopefully, this can be the first of many scripts I create and make available in this simplified way. Thus, I’d love you to try the program and tell me what you think. what works, what doesn’t? What would you like to see and how can it be improved? No matter what it is, I’d love to hear your thoughts, which you can send me directly via email

Look out for more updates and new scripts at my GitHub repository –

Anti spam policies in Microsoft 365

One of the biggest misunderstanding’s I see around Microsoft/Office 365 is managing anti spam settings. These are done in Exchange Online. Thinks like Office 365 ATP actually perform additional functionality (such as safe list and attachments). Thus, if you want to limit the spam that users receive it is important to ensure you have your anti spam policies correctly configured.

This video will show you how and where to configure both inbound and outbound spam policies as well as some best practice recommendations for both. You’ll find the direct link for the video here: