Need to Know podcast–Episode 253

FAQ podcasts are shorter and more focused on a particular topic. In this episode I speak about some automation options that are available in the Microsoft Cloud.

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

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.


FAQ 16

CIAOPS Patron Community


Updated CIAOPS PowerShell course

I am pleased to announce that I have updated my online PowerShell course for Microsoft 365. A lot has changed in recent times so I’ve been through the content and updated it as well as add lots more lessons and resources. The only thing that hasn’t changed is the price. That remains at US$39!

You can view the course content and sign up here:

Of course, if you are eligible CIAOPS Patron, you’ll also get immediate access to the course for free as part of your benefits.

The idea with the course is not to give you a deep dive into all the workings of PowerShell. It is designed to get you up and running using PowerShell with Microsoft 365 as quickly as possible. No pre-existing knowledge is assumed. I’m aiming to bring out more advanced courses, but this course is the foundation on which courses will be built.

As I have said many times here, PowerShell is a KEY skill for any IT Pro going forward in the Microsoft Cloud space. It allows you to do things faster and more consistently, just to name two benefits. If you haven’t taken the step to learning PowerShell then invest in yourself and you future and do so!

Automating the deployment of an Attack Surface Reduction policy across multiple tenants

A while ago I wrote an article on:

Using the Microsoft Graph with multiple tenants

which showed you how to embed a ‘static’ Azure AD application in all the tenants you wish. I then showed how to give those ‘static’ Azure AD applications, in all those tenants, the appropriate permissions to access various tenant configuration settings in this article:

Reporting on multiple tenants with the Microsoft Graph

This meant that you could now run Microsoft Graph requests across all those tenants, securely and without needing a login to each tenant.

Recently, I also wrote about the:

Attack Surface Reduction rules for Windows 10

and how to set these in an automated way via PowerShell. I’m now going to bring these two concepts together and show you how to deploy an Attack Surface Reduction (ASR) policy into Microsoft Endpoint Manager across multiple tenants WITHOUT the need to login to each to do it!

Before you can do all this you’ll need to embed an Azure AD App into all the desired tenants. The information to do this I have previously covered here:

Using the Microsoft Graph with multiple tenants

Once you have an Azure AD application inside your tenants you can continue to use this for continued configuration processes like this. Thus, you only need to add an Azure AD application to the desired tenants once. You can then simply re-use it as needed.

With the Azure AD application in place, the next step is to provide the appropriate permissions for that Azure AD application to do to what it needs. In the case of working with ASR the Azure AD application will need the following Graph API permissions:

Read and write Microsoft Intune Device Configuration and Policies


Read Microsoft Intune Device Configuration and Policies

You can add these manually which I have covered off previously here:

Using interactive PowerShell to access the Microsoft Graph

However, I have also made available an automated tool to do this.


In this case, my pre-existing Azure AD application is called ciaops-S6 as shown above.


In this first tenant, you see that there are current no API permissions associated with my Azure AD application.


In the second tenant, there are already existing permissions as you can see above, but they currently don’t include the ones I want detailed above, so they will also need to be added here.

What I want to achieve for both tenants, is to add these two Graph API permissions:

  • Read and write Microsoft Intune Device Configuration and Policies
  • Read Microsoft Intune Device Configuration and Policies

to my existing Azure AD application, while also leaving any existing permission in place.

You’ll need to visit my Office 365 GitHub repository and down the program:


You’ll need to put the graph-adapp.per.exe in the same directory as the XML configuration files for the tenant, as shown above. Then you’ll need to run:

graph-adapp-per.exe 89a0934cc6064c1a95caffdaec4e5429

The 89a0934cc6064c1a95caffdaec4e5429 parameter tells my program which permissions you wish to add to the existing Azure AD application.


The program will check whether the Azure AD PowerShell has been loaded. If not, it will terminate.

In this case enter A when prompted to ADD permission to those that exist.


You’ll then be prompted to login as an administrator to the first tenant. This is required once for each tenant because you are ADDING permissions to an existing Azure AD application. Once these permissions have been added, you won’t need to repeat for any access to the same properties. For example, say you later on want to configure the Microsoft EndPoint Manager Firewall policy, you won’t need to complete this permissions step because what you are doing here adds the same  permissions you need to do the Firewall policy.


The required permissions are added and you will be then prompted to ‘consent’ to these. Unfortunately, I can only find a way to do this via a browser. Selecting Y here will open a browser in-private mode and allow you to complete consent. The required ‘consent’ URL is also copied to the clipboard, so if you already have the tenant open is a browser somewhere, just paste the clipboard there to complete ‘consent’ like so:



You should now see the permissions request as shown above that you need to Accept. What you see will vary slightly. You will always see:

  • Read and write Microsoft Intune Device Configuration and Policies

  • Read Microsoft Intune Device Configuration and Policies

as these are new permissions. However, if you have existing rights, as this first tenant did, you will also see those.

Simply select Accept to continue.


If you now return to the program, you’ll be prompted to confirm that ‘consent’ has been completed. Enter Y to continue.


That will complete the first tenant and then commence the same process on all subsequent tenants as shown above.


The only difference you’ll probably see is the list of permissions you need to accept. This is because, in this case, the option to ADD permissions was selected. The above shows you the prompt from the second tenant in this example which started off with no permissions for the existing Azure AD application.


Once the program is complete, it will pause as ask you to hit ENTER as shown.


If you now look at the API permissions for the Azure AD application that was added you should see that they now have:

  • Read and write Microsoft Intune Device Configuration and Policies

  • Read Microsoft Intune Device Configuration and Policies

As shown above.


And if you check an Azure AD application that already had permissions, like the second example here shown above, you will see that the appropriate permissions have been added to any that previously existed.

Remember, you only need to go through this process when you want to ADD permissions to your Azure AD application. As mentioned, now that these permissions have been added to the Azure AD application you can work with just about any EndPoint Manager configuration for the tenant.

Now that the permissions are in place, the next step in the process is to run the program to add the ASR policy to EndPoint Manager for the tenant. To do that you’ll need to download the following program from my Office 365 GitHub repository:


and copy into the same directory you have been using as shown above. That is the one with all the tenant configuration files.

Run the program:



The program will run and work through the required tenants without any prompts.


You will see the policy settings for each tenant, as shown above, as a confirmation.


If you return to Microsoft EndPoint manager for the tenants and refresh that ASR policy listing as shown above, you should a new ASR policy as shown.


If you scroll down to the Configuration settings:


You will see that the individual settings have been configured.


The only you’ll need to do manually, is to actually assign this policy to your environment as shown above. I have chosen not to do this automatically for all users and or devices in the tenant, because there may need to some tweaking of the individual settings as applying to a test group first to ensure there are no issues. Maybe in a future iteration I’ll look at providing that option.

If you run the graph-asr-set.ps1 program again, it will create an additional policy of the same name with the same settings. Another to-do item will be a program to adjust an existing script.

If for some reason you wish to remove ALL the permissions from your Azure AD application in ALL your tenants, use the command:

graph-adapp-per.ps1 693cb755244848a2a556025710cec086

Youi can also, of course, do this manually via the portal as well as selectively by the same method if you wish. However, I see no major not to leave the permissions in place, having gone to all that trouble, so you can make additional configuration changes later on (without the need to login to the tenants as I will again point out!)

So there you have it! An automated way to set ASR policies in Microsoft EndPoint Manager, across multiple tenants, without individually logging in, using the Microsoft Graph.

Case sensitivity is important with the Microsoft Graph

I recently wrote an article about implementing Attack Service Reduction (ASR) which you can read here:

Attack Surface Reduction for Windows 10

The next step was now to automate ASR policies with Microsoft EndPoint Manager via PowerShell. Luckily I found a great blog article by Ben Leader which you’ll find here:

Creating EndPoint Security policies with PowerShell

Ben’s article focused on BitLocker, while mine focused an ASR. It took a little time to reverse engineer things with ASR and I had my script working without error.


However, the problem was that the changes that the script made didn’t show up in the web interface as shown above? There were no errors reported. Strange? Maybe, it was a timing thing? Nope. what could it be?

Puzzled, I contacted Ben again and it turns out that the syntax with the Microsoft Graph is case sensitive!. A simple solution once you know but super frustrating until your do.


So the original code I have set the “value” to Enable as shown above. That is with a capital ‘E’, which is invalid.


As it turns out (thanks to Ben), I learned it should be a lower case ‘e’ as shown above.


As shown above, this works as expected in the web interface. Phew.

The moral or the story is that you need to be careful when it comes to setting values with the Graph. That hopefully, hopefully should accelerate my development of automating ASR across environments!

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.

An easier way to connect using PowerShell

If you visit my Office 365 GitHub repository, you’ll find a whole of scripts there you can use for free. A subset of those scripts are designed to make connecting to the various Microsoft Cloud service easier. For example the script:

allows you to easily connect to Exchange Online using the version 2 module.

While all of this helps, it can still be a bit trickly for people to know what to run when to get connected. So, with that in mind I have created this script:

which when run by simply typing


in the PowerShell command line


will now pop up a dialog as shown above and allow you to select which service which wish to connect to.


Even better, you can also select multiple services in this same window. You simply use the CTRL and SHIFT keys to select multiple item, just as you do in any Windows desktop application (like Windows Explorer for files say).

After you have made your selection, those individual service connection scripts will be run.

Of course, the assumption is that you have all of my scripts (including the individual connection scripts) in the same directory. If not, then the connections will not be made. However, if you have ‘cloned’ what I have into a single location on your machine, then you should be all good.

I also created this short script:

which you can run at the PowerShell command prompt via:


to remove any currently loaded PowerShell sessions as well, quickly and easily.

Hopefully, this new ‘master connection’ script will make it easier for people to connect to the Microsoft Cloud services they need.

Make you you check back regularly to my Github repository for any updates and additions

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