Offboarding Windows 10 devices from Microsoft Defender for Business

In a recent article I covered off how to:

Onboard Windows 10 devices to Microsoft Defender for Business

Two easy methods of onboarding Windows 10 devices to Defender for Business

Now we need to know how to offboard Windows 10 devices from Microsoft Defender for Business.

The first place to start is to review this article from Microsoft:

Offboard devices from the Microsoft Defender for Endpoint service

It details the following points:

– The status of a device will be switched to Inactive 7 days after offboarding.

– Offboarded devices’ data (such as Timeline, Alerts, Vulnerabilities, etc.) will remain in the portal until the configured retention period expires.

– The device’s profile (without data) will remain in the Devices List for no longer than 180 days.

– In addition, devices that are not active in the last 30 days are not factored in on the data that reflects your organization’s threat and vulnerability management exposure score and Microsoft Secure Score for Devices.

– To view only active devices, you can filter by health state, device tags or machine groups.

In essence what this means is that although you offboard a device a lot of information about that device will remain in the portal. Also, even after offboarding a device, if you look in the Endpoint portal, at first glance the device still appears to be there. The reality is that offboarding a device doesn’t make it ‘disappear’ from the portal immediately. This means we’ll need to use another method to verify that the device has actually been offboarded.


The easiest way is to look in the following registry key on the machine:

HKLM:\Software\Microsoft\Windows Advanced Threat Protection\Status

and examine the value of the key:


If that is set to 1, as shown above, then the device is still considered connected to Microsoft Defender fo Endpoint. Thus, to confirm the device has been offboarded, we need to check that this value is 0.

You’ll also need to have a license for Intune/Endpoint Manager to enable this process from a centralised location.

Although not completely necessary it is best practice to have the integration between Microsoft Endpoint Manager portal and Defender for Endpoint enabled. Visit:


As shown above, here, navigate to Endpoint Security, then Microsoft Defender for Endpoint. Ensure that the option Connection status is enabled. If it isn’t then take a look at my previous onboarding article that shows you how to enable this.

Next, navigate to:


You should see the screen above. Scroll down this page.


Select Settings as shown above and then Endpoints from the options that appear on the right.


From the menu on left scroll down and select Offboarding. On the right then select Windows 10 and 11 as the operating system. Then select Mobile Device Management / Microsoft Intune. With these selections made a Download package button should appear. Select this to download a zip file that contains a file called WindowsDefenderATP_valid_until_YYYY-MM-DD.offboarding

For security reasons, the package used to Offboard devices will expire 30 days after the date it was downloaded. Expired offboarding packages sent to a device will be rejected. That expiry date will be contained in the filename.


Navigate back to Microsoft Endpoint Manager and select Devices | Configuration profiles, then Create Profile.


Select Windows 10 and later for the Platform and Templates from the Profile type.


Select Custom from the list and then Create.


Give the policy a name and description and select Next to continue.


Select the Add button.


Enter the following details into the fields that appear on the right as shown above:

Name = <unique name>

OMA-URI = ./Device/Vendor/MSFT/WindowsAdvancedThreatProtection/Offboarding

Data type = String

Value = <contents of the unzipped file WindowsDefenderATP_valid_until_YYYY-MM-DD.offboarding downloaded from Defender for Endpoint portal>


The WindowsDefenderATP_valid_until_YYYY-MM-DD.offboarding file can be opened with Notepad and should look like the above.

Press the Save button to continue.


The Configuration settings page should now look like the above with the single entry you just configured.

Press the Next button to continue.


You now need to select which items this policy will apply to. In general, you are not going to be offboard all your devices at the same time from Defender for Endpoint. What we need to do then is target a specific group of devices.

A good approach to achieving this is to create a dedicated device group, with only the devices you wish to offboard with this policy. I detailed how to create such a group in Azure AD here:

Create a dynamic group in Azure AD

In this case, the dynamic group is called To be retired and I will assign it to the Intune policy as shown above.

Continue to select Next and then Create to complete the policy creation process.


If you select the Device status option as shown above, you’ll see whether the policy has been successfully applied to the devices. How long this takes will depend on when the devices ‘check in’ to get the policy.

As mentioned initially, there is no easy way to confirm that the device has successfully been offboarded unless you look at the registry key:

HKLM:\Software\Microsoft\Windows Advanced Threat Protection\Status\OnboardingState

and ensure that it is equal to 0. To assist with this I have created this free PowerShell script:


That will show you the onboarding status as shown above.

Also, remember that the device will continue to be displayed in the Defender for Endpoint unless you use a display filter. Offboarding causes the device to stop sending sensor data to the portal but data from the device, including reference to any alerts it has had will be retained for up to 6 months.

If you want to offboard more devices you simply need to add them to the group you configured the offboarding Intune policy is assigned to. Remember, that after 30 days you’ll need to go and download a new offboarding package from the Defender for Endpoint console and upload the contents of the new WindowsDefenderATP_valid_until_YYYY-MM-DD.offboarding file to the offboarding Intune policy to allow devices to be successfully offboarded going forward. However, you can leave the policy in place and simply update it as and when needed.

Windows 10 in cloud configuration

Microsoft has released a handy guide called

Windows 10 in cloud configuration

that walks you through a recommended best practice configuration of you Windows 10 devices using Endpoint Manager. what they are now doing, as highlighted by my video, is begin to roll this into a wizard inside the Endpoint Manager portal, allowing you to quickly and easily create and apply policies to protection your Windows 10 machines.

I believe this in only the beginning of what Microsoft plans to roll out and I expect to see lots more configuration coming very soon, not only for Windows 10 but also iOS and Android.

Watch this space.

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.