Deploying Microsoft 365 Apps Device-based Licensing for EDU


Update 5/13/20: Microsoft has recently updated the name of “Office 365 ProPlus” to “Microsoft 365 Apps”. The majority of this post has been updated to reflect those changes. In addition the OSD section has been updated and a new section called “DBA Clean Up”.


Hi there! It’s been a while! The last blog I wrote was roughly two and a half years ago, where I wrote a step by step guide to deploy Office 365 ProPlus with Device Based Activation (DBA) with SCCM. In that time, the blog post has accumulated over 20k views from schools all over the world! So thank you to everyone for making it so successful and I hope it served as a great resource! Hopefully, you will find this post as valuable as the last one.

Today, I’m excited to provide a follow up to that post with how to deploy Microsoft 365 Apps with Device-based Subscription (DBS), sometimes referred to as Device-based licensing, using both ConfigMgr and Intune. I would highly recommend a look-see at the previous blog if you want some historical background.

In August 2019, Microsoft officially announced DBS so I want to go into a little bit of depth what’s different from DBA, and how to configure and deploy DBS in your environment. I’m also going to touch on how to migrate from DBA to DBS, should that be your case. Please note that DBA and DBS essentially achieve the same outcome: providing a working activation method for the Microsoft 365 Apps client, primarily to fit EDU scenarios where shared carts, computer labs and kiosk devices are more common than in the commercial sector.

I’ve broken this walkthrough up into a few parts for easier consumption:

  1. DBA vs DBS
  2. Requirements
  3. Configuration of Pre-reqs
  4. Deployment of Microsoft 365 Apps
  5. Test the deployment and end-user experience
  6. What about OSD?
  7. Migrate from DBA to DBS
  8. What about MacOS?
  9. Resources and additional information
  10. Feedback

DBA vs DBS vs Shared Computer Activation (SCA)

So, if the outcome is the same, why the change in deployment technologies? There are a number of reasons, but I would argue the biggest is support. DBA was essentially a field solution created to help EDU organizations quickly and successfully deploy Office 365 Pro Plus client to their devices so students, faculty and staff could take advantage of the latest updates to Office 365, instead of running legacy, feature-limited Office 2013/16/19 clients. However, if there was an issue with Microsoft 365 Apps clients activated with DBA, support was limited. DBA wasn’t supported by Premier/CSS like most Microsoft solutions. So if someone from the Microsoft EDU team wasn’t able to assist/resolve the issue, you were basically on your own. In fact, the only resources out there for DBA were my previous blog post and a collection of FAQ’s located here. No technical documentation on like you would typically expect.

DBS was created to achieve the same results of DBA, but in a fully supported fashion. Full list of benefits include:

  • Full support with Premier/CSS as mentioned above, including technical documentation on
  • Support for countries and regions outside of the United States
  • No longer a dependency on a separate application to initiate the Office install (OPPTransition.exe)
  • No need for the elusive “Office 365 A1 Plus for Students” license to be obtained
  • In certain reimaging scenarios, Office would not activate unless an admin granted the DBA web service password reset capabilities in the tenant, usually by using a PowerShell script
  • No more bloated Azure AD with the number of user accounts that were created for each device that was activated with OPPTransition
  • Direct configuration inside the standard configuration.xml used with the Office Deployment Toolkit

Shared Computer Activation (SCA) has been around for a number of years, but it did not quite solve the challenges EDU historically has faced. It still required an Internet connection with a user sign-in upon launch, per profile. We could not assume that all students had an internet connection at home when they took a checkout device home from school. SCA is still a good option for VDI or RDS scenarios, however.


Before you can deploy DBS in your environment there are some pre-reqs including:

  • A valid Microsoft 365 Apps, Office 365 A3/A5 or Microsoft A3/A5 subscription
    • “Microsoft 365 Apps for Education (device)” SKU added via the Microsoft Admin Portal – walkthrough below.
  • Windows 10 1803 or above
  • Microsoft 365 Apps build version 1907 or above
  • Device must be Azure AD joined or Hybrid Azure AD joined
  • The latest Office Deployment Tool (ODT) release (just as a best practice)
  • The latest release of the Microsoft 365 Apps ADMX Templates

Configuration of Pre-Reqs

In this section, I will detail how to get each of the pre-reqs configured to ensure a successful DBS deployment.

1. Obtaining “Microsoft 365 Apps for Education (device)” SKU

First things first. We need to get the “Microsoft 365 Apps for Education (device)” SKU added to our tenant. To do this, you must submit a request to your reseller. You can request up to 40x the number of Education Qualified Users (EQUs) that you license with Microsoft 365 Apps, or Office/Microsoft 365 A3/A5. The time it takes to request this and see the licenses in your tenant varies, so be sure to plan ahead. Your reseller should contact you letting you know the process is complete.

To verify, let’s jump into the NEW Microsoft Admin Center. You can tell if it’s the new one by the toggle in the upper right-hand corner is enabled (blue):

Annotation 2019-11-14 155723

Go to Billing -> Licenses and you should now see the “Microsoft 365 Apps for Education (device)” SKU, similar to below (although yours will say Education and not enteprise):

2. Ensure your devices are Hybrid Azure AD joined, or full Azure AD joined

Deploy Hybrid Azure AD is a little out of scope of this blog. However, Microsoft Docs have some pretty well-written articles to help you define the scope and requirements of Hybrid Join and even some how-to guides. Use these resources to plan your deployment. It’s fairly straightforward. Plus, if you have ConfigMgr today, you’ll want to hybrid join your lab and teacher devices, so you can take advantage of co-management and leverage the entire Microsoft Endpoint Manager solution suite to your liking.

For student devices, I still recommend going full Azure AD join, but that’s another topic for another blog.

3. Create a Device Group

I’m going to admit, this is a little tricky. It’s definitely easier said than done. We can create a manual (or assigned) group and add devices in ad-hoc, which is great for testing. We can also create a dynamic group so that all your devices will fall in automatically. To add to the decision-making process, you can create groups in multiple admin centers. You can create it in the Microsoft Admin Center (but only an assigned group), you can create it in Azure AD (AAD), or you can create it in Intune! You can also leverage an existing group if you have one, already.

For the purposes of this walkthrough, I’m going to create a dynamic device group in AAD because this suits most universities and school districts I work with.

  1. Open the Azure Active Directory portal
  2. Click on Groups
  3. Click New group
  4. For Group type choose Security
  5. Give it a name under Group name
  6. Give it a description if necessary
  7. Under Membership type, choose Dynamic Device
  8. Click on Dynamic device members Add dynamic query
  9. Use the following:
    1. Property: deviceOSType
    2. Operator: contains
    3. Value: Windows
  10. Add another expression
    1. Property: deviceOSVersion
    2. Operator: Match
    3. Value: [10][.][0][.]1713[4-9]|171[4-9]\d|17[2-9]\d{2}|1[8-9]\d{3}|[2-9]\d{4}|\d{6,}

      In the end, your Rule syntax should look something like this:

      (device.deviceOSType -contains “Windows”) and (device.deviceOSVersion -match “[10][.][0][.]1713[4-9]|171[4-9]\d|17[2-9]\d{2}|1[8-9]\d{3}|[2-9]\d{4}|\d{6,}”)

  11. Click Save
  12. Click Create

The above value is a little nasty, but necessary to help us pull in all devices Windows 10 1803 and newer. In AAD, dynamic queries are created with strings. So operators like “<” and “>” (less than and greater than) do not work. Thanks, Eswar Koneti, for the string above. We pull in all Windows devices 1803 and newer because that is the pre-req for DBS to work with. If we simply kept the OSVersion, we might pull other devices like iOS and Android devices which we don’t want to do. Once created, depending on the number of devices in AAD that meet the criteria, it may take a little while to populate. If you have no hybrid or AAD joined machines yet, then your group will not populate anything.

4. Assign the license to your group

Regardless of the method you choose to create the group, know that we can only assign the “Microsoft 365 Apps for Education (device)” SKU to the appropriate group in the Microsoft Admin Center or with PowerShell! Did you catch that? I’ll re-state in other words:

If you try to use the AAD portal to assign the license to your group, your attempts will ultimately lead to failure. The SKU is not visible in the AAD console at this time.

So, we are going to jump back into our NEW Microsoft Admin Portal.

  1. Click Billing
  2. Click Licenses
  3. Click the Microsoft 365 Apps for Education (device) license
  4. Click Assign licenses
    Annotation 2019-11-14 185845
  5. In the Assign licenses to a group flyout, click the field and select your group you created.
    Annotation 2019-11-14 185913.png
  6. Click Assign

5. Configure Microsoft 365 Apps to use device-based licensing

We have a couple of ways to configure Microsoft 365 Apps to use the new device-based licensing. We can use the Office Deployment Tool (which is a nice way of saying we are going to leverage the configuration.xml) or we can use Group Policy/MDM. I’m going to show you the configuration.xml method because I want to focus on new deployments at the moment. The Group Policy method will be addressed later in the blog.

Office Customization Tool

Have you used the online Office Customization Tool yet? It’s different than the previous Office Customization Tool we had when deploying legacy, volume-licensed, MSI-based Office installs (2010/2013/2016). This new one is online and more modern, by using a configuration file in XML format, versus a customized .msp installer! We are going to use this to define our configuration.xml, but it’s not necessary. If you have questions on specific properties or elements it the config file and the expected behavior, refer to the Microsoft official documentation for editing the configuration.xml by hand or making an informed decision.

  1. Visit
  2. Sign in
  3. On the left hand side, ensure Customization is selected
  4. Under the My configurations tab, click Create
    Annotation 2019-11-14 195315.png
  5. Give your configuration a name.
    Annotation 2019-11-14 195410.png
  6. Select the appropriate architecture (I generally recommend 64-bit).
  7. Under the Products section, under Office Suites, select Microsoft 365 Apps.
  8. Under Update channel select Current Channel, and select the Latest version
  9. Under Apps, select which apps are appropriate for your environment.

    A few notes: It is a best practice to keep the OneDrive (Groove) disabled. Microsoft recently announced they are resurrecting OneNote 2016, so feel free to re-enable that. Teams is also very popular and has some incredible classroom features, so I would leave that enabled and disable Skype for Business.

  10. Once configured to your liking, click Next
  11. Under Languages, select the appropriate language. I personally like the Match Operating System option.
  12. Under Installation, select where you want the source files of Office to come from. You’ve got some options, so to understand what is best for your environment, refer to the documentation I mentioned at the top of this section. I’m going to select the following for the purposes of this blog.
    Annotation 2019-11-14 201354.png
  13. Click Next
  14. Under Update and upgrade options you have a similar number of decisions to make, so think this through carefully and define as needed. Below is just what I’m using for the purposes of this blog.Annotation 2019-11-14 201304.pngAnnotation 2019-11-14 201205.png
  15. Click Next
  16. Under Licensing and activation is key for using Device-based licensing
    1. Automatically accept the EULA
      Annotation 2019-11-14 201555.png
    2. Under Product Activation, select the Device based radio buttonAnnotation 2019-11-14 201813
  17. Click Next
  18. And fill in the General and Application Preference as desired
  19. Click Finish
  20. You can review all the settings you set on the far right-hand side. Take a look at that and make sure all looks good. Then, at the very top click Download.
    Annotation 2019-11-14 202041
    (If prompted, select Keep Current Settings for the Default File Format dialog, and click OK.)
  21. Click Download one more time.
  22. Open your recently downloaded config file in your text editor of your choice. Notice that there is a specific property and value written:

    <Property Name=“DeviceBasedLicensing” Value=“1” />

    Annotation 2019-11-14 202333

This property is going to set the following reg key upon deployment:

HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Configuration\O365ProPlusRetail.DeviceBasedLicensing with a value of “1”.

At this point, all the proper configurations and pre-reqs should be in place and you should be ready to create your deployment of Microsoft 365 Apps with device-based licensing.

Deploy Microsoft 365 Apps with Device-based Licensing

There are many ways to deploy Microsoft 365 Apps, the application itself. I’m focusing on how to do it from Microsoft Endpoint Manager (both ConfigMgr and Intune), which simplifies the deployment process for Office.

ConfigMgr Deployment

A lot of Universities and School Districts are using ConfigMgr as their primary device management solution. To deploy Microsoft 365 Apps with Device-based licensing to your client follow the instructions below.

If you wish to use ConfigMgr to manage the Microsoft 365 Apps updates after deployment, be sure to verify you selected you want the updates to come from Configuration Manager in your configuration.xml. This is noted by the property value OfficeMgmtCOM=”True”

  1. Open your ConfigMgr console
  2. Click on the Software Library workspace
  3. Click on Office 365 Client Management
  4. Click on Office 365 Installer
    Annotation 2019-11-14 204546

  5. Give your Application a name, description and point to the content location
    Annotation 2019-11-14 204906

  6. Click Next
  7. Click Go to Office Customization Tool
  8. Because we have already created our XML earlier, we can simply import the one we downloaded. However, notice that some of the settings are slightly different, so you may have to make a few tweaks. When satisfied, click Review and then Submit.
    Annotation 2019-11-14 205203

  9. Click Next
  10. You have the option to deploy the application or not. If you are familiar with ConfigMgr, go ahead and select your target collection of devices as you normally would (but make sure its the same devices that are being licensed in the AAD group we created earlier!). If you need a primer on app deployment in ConfigMgr visit this link:
  11. The Progress page may take a while, because ConfigMgr is going to do all the work of downloading the actual Office bits and create the application for you. Once completed, you should see a similar folder structure below:
    Annotation 2019-11-14 210229

Make sure you are using the latest version of ConfigMgr, but know that at the very least starting In version 1602, the ConfigMgr team introduced a new way to help manage Microsoft 365 Apps Client updates. The Office 365 Client Management node now provides an in-console view to your Microsoft 365 Apps clients. Complete with charts and graphs to make any manager happy, you can quickly visualize the state of your Microsoft 365 Apps clients in your environment. Learn more here:

I’ll show you what actual client/end-user experience is to validate our configuration and deployment worked correctly below.

Intune Deployment

We can also use Intune to deploy Microsoft 365 Apps with Device-based licensing. This is useful for full AAD joined machines, but also for Hybrid-joined machines that are co-managed.

  1. Browse to the Microsoft Endpoint Manager Admin Console.
  2. Click on Apps
  3. Click All apps
  4. Click Add
  5. Under App type, select Windows 10 under the Office 365 Suite section
  6. You now have the option to use the Configuration designer or Enter XML data under the Setting format.
    The configuration designer is very nice, however as of the time of this writing, the device-based license option is not exposed in the UI. For the time being, and since we have already created our XML, we are going to proceed with Enter XML data
  7. Click the App Suite Information option and provide a name and description for the app
    Annotation 2019-11-14 213523.png

  8. Click OK
  9. Click Enter XML data
  10. Copy and paste the XML contents from your XML to the configuration file text field
    Annotation 2019-11-14 213531.png

  11. Click OK
  12. Click Add
  13. You’ll land at the Overview page of the application just created. Now, we need to assign the application to a group of devices. Click Assignments.
  14. Click Add group
  15. Select the Assignment type as desired. I’m choosing Required for the purposes of this blog.
  16. Select the Included Groups option and click Select the groups to include box and select your group by searching via the flyout window.
    Annotation 2019-11-14 214502.png

  17. Click Select
  18. Click OK
  19. Click OK
  20. Click Save

Third-party Management Tools

If you are using another deployment technology, you will have to rely on using the Office Deployment Toolkit, downloading setup.exe and using the /configure option to reference your configuration.xml. Setup.exe will download the necessary bits and allow you to package the application and use the management tool you have in place to deploy the app as you normally would. More info can be found here:

Test the deployment and end-user experience

At this point, we’ve put the pre-reqs in place, we’ve configured the Office install to our liking, we’ve created our deployment based on our preferred deployment technology….now it’s time to test the install and verify the end-user experience is as we desire.

What happens with install of Office at this point is when the client is installed, the proper registry key is going to be written which will instruct the Office Licensing Service to contact the specific tenant the device is joined to, to look for a valid license per its group membership. If a valid license is found, it passes that info back to the device via OLS and registers the client to “This device”, which we will see when we launch an Office product and look at the registered owner. It’s a very complex sequence of events, so kudos to Microsoft engineering for figuring this one out.

Once you see that Office has successfully installed, let’s check out the registry to see if the key exists. Sure enough, based on the configuration, the DeviceBasedLicensing key is present and set to a value of  “1”. 

Annotation 2019-11-14 221638.png

When you go to launch Word for the first time, you will notice that the logged in user is automatically signed into Office, and if we go to File -> Account, you’ll notice that the product is now registered to “This device”. 

Annotation 2019-11-14 223058.png

Depending on what the end-user who is using the Microsoft 365 Apps client is licensed for, the experience of Office may be a little bit different. Here’s an easy guide to help you understand the expected experience: 

A3/A5 licensed user:

  • Sign-in with your organization ID
  • Access Microsoft 365 Apps desktop apps
  • Collaborate in real-time under your name
  • Access your OneDrive files and your Exchange email

A1 licensed user:

  • Sign-in with your organization ID
  • Access Microsoft 365 Apps desktop apps
  • Collaborate in real-time under your name
  • Access your OneDrive files and Exchange email (as licensed)

Non-licensed user:

  • Sign-in as guest or not required
  • Access Microsoft 365 Apps desktop apps
  • Save files to the device

What about OSD?

I get this question a lot. I am going to suggest you take a look at Autopilot for your future Windows deployment needs as we can join directly to AAD or even Hybrid AAD coming soon (in preview today)!

Until then, baking Office into your gold image is still a viable option. In the past, I have referenced Mikael Nystrom, aka the Deployment Bunny’s blog, as he has a super useful script to put the Office 365 ProPlus client in your reference image the correct way. Still relevant….an oldie but a goodie. Make sure when you build the image you just have DeviceBasedLicensing=1 property in config.xml when you install Office on the base .wim. That’s my recommendation for fastest activation. 

The trick with DBS is that we have to get the device record up into AAD in a timely manner after deployment in order for the license to take effect before the first user who logs in to that device launches an Office product. If the Microsoft 365 Apps client isn’t properly licensed before use, the end user will be in a “reduced functionality” mode.

If you’re testing HAADJ for the first time, signing in within 30 minutes of imaging completing (whether using SCCM or not), you’ll likely end up in a state where the device doesn’t HAADJ. If you image and let the device sit for awhile (30+ minutes) and then sign in, the join will likely be successful. This is because the Microsoft > Windows > Workplace Join > Automatic-Device-Join scheduled task is triggered on sign on of a user or when the User Device Registration event ID 4096 is triggered (unknown to me as to when this gets triggered). If you sign in before AAD connect has had a chance to sync the computer object, you’ll be waiting indefinitely. Best at this point to sign out/sign in.  In most cases this shouldn’t be a problem as once the device domain joins the HAADJ process is queued up and waiting for AAD connect to sync. The user that signs on normally will sign on well after 30 minutes have passed after imaging a new device. Also note that this delay really occurs on a new device that doesn’t have a device record up in AAD.

Migration from DBA to DBS

If you are currently using Microsoft 365 Apps (including DBA) today, there’s some good news: a reinstall of Microsoft 365 Apps is NOT required! I repeat, an install is NOT required! Hallelujah!

As long as the device meets the pre-reqs (Win10 v1803 or higher, Microsoft 365 Apps installed is v1907 and higher, and the device is Hybrid AAD joined or full AAD joined) then you are good to go. A simple registry key addition will flip the current Office install from a user-based (which DBA actually is) to the new and true device-based with no end-user impact.

We can achieve this by using the Group Policy (and hopefully MDM soon) method for deploying the reg key change, or we can use a Configuration Item with ConfigMgr to set the key. According to the official documentation please note: 

To use this policy setting, download version 4909.1000 (or later) of the Administrative Template files (ADMX/ADML) for Microsoft 365 Apps from the Microsoft Download Center. Version 4909.1000 was released on September 5, 2019.

You can leverage the “Use a device-based license for Microsoft 365 Apps” policy setting in the admin template to set the appropriate reg key. This policy setting can be found under Computer Configuration\Policies\Administrative Templates\Microsoft Office 2016 (Machine)\Licensing Settings. The correlating registry key is HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Configuration\O365ProPlusRetail.DeviceBasedLicensing with a value of “1”.

Note: Once you deploy the reg key and it takes effect, if you had a user-activated Microsoft 365 Apps client, the user license is still consumed. The end-user will need to go unlicense any devices that have been activated under their name via their O365 portal login to recoup that license.

DBA Clean Up

Once you have successfully migrated your devices to your environment to DBS or another supported Microsoft 365 Apps activation method, you can remove the remnants of DBA in your environment. Below is a script I have written to help with that clean up.

To walkthrough the process, the script will prompt you to connect to Azure AD and then it will remove all users that start with _Device_. Then it will remove the service principal that was added to your tenant when you authorized access to the DBA web service when you signed up.

 function Receive-Output 
    process {Write-Host $_ -ForegroundColor Green}

#Connect to Azure AD Service
Write-Output "Connecting to Azure AD..." | Receive-Output

#Remove DBA device user accounts from AzureAD
Write-Output "Removing all users in AAD starting with '_Device_'..." | Receive-Output
$DeviceUsers = Get-AzureADUser -Filter "startswith(displayName,'_Device_')"
Remove-AzureADUser -ObjectId $DeviceUsers.ObjectId

#Remove DBA Service Principal from Tenant
Write-Output "Removing DBA service from the tenant..." | Receive-Output
$ObjectID = (Get-AzureADServicePrincipal -All $true | Where-Object -Property AppID -eq "300e65c0-b3f4-4b46-b3d5-51d99dda4edf").ObjectID
Remove-AzureADServicePrincipal -ObjectId $ObjectID

Write-Output "Success! All instances of Microsoft Office Device Based Activation have been removed from your tenant!" | Receive-Output

Feel free to adapt this script to meet your needs but use at your own risk. Word of caution: the DBA sign up link has been removed, so there is no way to get the service principal back into your environment, once removed. In addition, make sure ALL your devices have migrated to a new activation method before deleting those users. If the user doesn’t exist, when your Microsoft 365 Apps client attempt to rearm via the Office Licensing Service, it will fail to grab the license and therefore deactivate and enter reduced functionality mode.

What about MacOS?

I also hear the request for Microsoft 365 Apps DBS on MacOS devices. Today this is not supported. It’s currently a limitation of being able to join MacOS devices to AAD, to get them into the dynamic group, to license them with the appropriate SKU.

I have created a UserVoice item for you to upvote this with the Microsoft 365 engineering team. They will prioritize based on your feedback, so please take a moment to upvote if this is relevant to you and your organization.


New and flexible way to use Microsoft 365 Apps on your shared devices –

PointDrive of curated Microsoft 365 Apps DBS Resources

Troubleshooting device-based licensing for Microsoft 365 Apps –


Questions, comments, concerns? Comment below so I can make this blog more useful to your planning and deployment strategy.