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:

Blocked files types in OWA

Outlook Web Access maintain a list of allowed and blocked file types. These are contained in a policy for each user. To determine what this policy is with PowerShell, the first thing you’ll need to do is connect to Exchange Online. I have made that easy for you by creating a script to connect using the new Exchange Online V2 PowerShell module. you will find that script here:

Once you have connected, run the following commands:

$casmailbox=Get-CASMailbox <user email address>
$owapolicyname = $casmailbox.OwaMailboxPolicy

This should display something like:


which gives us the policy name.

Next run the command:

$policy = Get-OwaMailboxPolicy $owapolicyname

to get the settings/values of that policy.

To view the allowed file list run the commands:

$allowedFileTypes = $policy.AllowedFileTypes


which should show something like:


To view the blocked file list run the commands:

$blockedfiletypes = $policy.BlockedFileTypes


The next question is, can you adjust these lists? Yes you can. You basically do that by adjusting the list of extensions variable (here $blockedfiletypes) via something like:


and reapplying that to the policy like:

Set-OwaMailboxPolicy $policy -BlockedFileTypes $blockedFileTypes

and if you want to extend the list just use add instead of remove in the above command prior to applying it to the policy.

Microsoft is making additions to the BlockedFileTypes list from April 2020:

What file extensions will be added to the BlockedFileTypes list with this change?
The following extensions are used by the Python scripting language:

“.py”, “.pyc”, “.pyo”, “.pyw”, “.pyz”, “.pyzw”

The following extensions are used by the PowerShell scripting language:

“.ps1”, “.ps1xml”, “.ps2”, “.ps2xml”, “.psc1”, “.psc2”, “.psd1”, “.psdm1”, “.cdxml”, “.pssc”

The following extension is used by Windows ClickOnce


The following extension is used by Microsoft Data Access Components (MDAC)


The following extension is used by the Windows sandbox


The following extensions are used for digital certificates:

“.cer”, “.crt”, “.der”

The following extensions are used by the Java programming language:

“.jar”, “.jnlp”

The following extensions are used by various applications. While the associated vulnerabilities have been patched (for years, in most cases), they are being blocked for the benefit of organizations that might still have older versions of the application software in use:

“.appcontent-ms”, “.settingcontent-ms”, “.cnt”, “.hpj”, “.website”, “.webpnp”, “.mcf”, “.printerexport”, “.pl”, “.theme”, “.vbp”, “.xbap”, “.xll”, “.xnk”, “.msu”, “.diagcab”, “.grp”

The list in my test tenant right now is:

Blocked File Types:


and Allowed File Types is:


Your mileage may vary.

What supports modern authentication in Microsoft 365

I get a lot of questions of what does and doesn’t support pure modern authentication in Microsoft 365. Pure modern authentication DOESN’T include App Passwords!

In short, you are best off with the latest version of the Microsoft software. However, here’s the list:

Office 2016

Modern authentication is already enabled for Office 2016 clients, you do not need to set registry keys for Office 2016.

Office 2013

To enable modern authentication for any devices running Windows (for example on laptops and tablets), that have Microsoft Office 2013 installed, you need to set the following registry keys. The keys have to be set on each device that you want to enable for modern authentication:

Registry key        Type        Value

HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Identity\EnableADAL        REG_DWORD        1

HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Identity\Version        REG_DWORD        1


In order to use the native iOS mail client, you will need to be running iOS version 11.0 or later to ensure the mail client has been updated to block legacy authentication.


One of the three most recent versions of macOS. When a new major version of macOS is released, the macOS and the previous two versions.

macOS Mail on macOS < 10.14 does not support Modern Authentication


Android (Google) Mail does not support Modern Authentication

Outlook on mobile

Outlook for Mobile supports modern authentication by default

Office for iPad® and iPhone® (including Outlook for iOS on iPad® and iPhone®) requires iOS 12.0 or later. Office for iPad Pro™ requires iOS 11.0 or later Office is supported on the two most recent versions of iOS.

Office for Android can be installed on tablets and phones running any of the supported versions of Android and have an ARM-based or Intel x86 processor. Starting on July 1, 2019, support will be limited to only the last four major versions of Android.

Office for Android™ can be installed on tablets and phones that meet the following criteria: running Android KitKat 4.4 or later version and have an ARM-based or Intel x86 processor.

Compare how different mobile devices work with Office 365 –