Information technology tools and resources at the UW
Office ProPlus Device Based Activation Analysis
This page provides analysis related to enabling Office ProPlus Device Based Activation.
This topic has had some discussion on the ms-tech mailing list. Scott Norton, MSCA service owner, opened REQ1216482 about this topic, but let the request close without response.
There are variety of ways to get and license Microsoft Office. At the UW, the two most common are:
- Office via Microsoft Volume License available as part of the UW Campus agreement
- Office 365 ProPlus via Office 365 available as part of the UW Campus agreement
To be clear, there are several other options, including Office versions for mobile platforms.
There are a variety of names folks use to describe these two most common Microsoft Office clients. These include “Click to Run” (#2), “Fat client” (#1), and others.
These two common Microsoft Office options differ in some key ways. Here’s a table that shows a few key differences:
|License activation||Must apply MAK or KMS to activate license||Must have an appropriate license applied to your Azure AD user object|
|Licensing approach||By computer||By user|
|Method of install||MSI based installer||Click to run based installer|
|Feature availability||Features show up months or more after introduced||Features introduced immediately on a continual basis|
|Interoperability with O365||Limited support from Microsoft, ends 2020.||Full support from Microsoft|
You can not mix #1 & #2 on the same computer.
Choosing a preferred Office version and method of activation
At face value, #2 appears superior to #1, and Microsoft certainly recommends it as the best option.
The one downside to #2 is the method of license activation. Users are limited to 5 install activations.
There are many shared computers at the UW. With #2, there is an option to do “shared activation” on a shared computer which does not count against the 5 limit, but the reality of that option is user annoyance. In more detail, this option means that the first time a user uses Office on that computer, they are presented with an interactive dialog where they must enter their UW user account and assuming the computer can connect to Microsoft, they can use Office. If they continue to use that computer over continuing days or the computer is offline, they will need to go through that same interactive dialog process.
There is one other license activation option for #2 which Microsoft calls “device user based activation”. At this time, this option is only available to the Education sector. Conceptually, this option is effectively activating the license by device. As such, it is not subject to the 5 per user install limit. It also does not have the interactive dialog user annoyance. So this is a great option for the UW. But before we jump all in on this option, there are a number of details behind the scenes which are critical to consider.
While conceptually “device user based activation” is device based, in reality it is still user based. In other words, if you use this option for a given computer, the end result is that a special purpose new Azure AD user object is created and an appropriate license is assigned to that special purpose AAD user object. If all of the existing users of #2 were to switch to this activation method, this would mean ~100K new Azure AD users in our tenant. Note that these special-purpose users would never go away, they’d only ever increase. There are a variety of implications here.
So while there is a clearly preferred method, there is a problem to solve …
How to enable Office ProPlus Device User Based Activation in a supported way
To enable this solution, Microsoft requires a couple things:
- to create an Azure AD application identity for a special Microsoft-run application that implements the license activation details
- to grant that AAD app sufficient admin permissions to do that work (note: this set of permissions falls into a category we consider risky)
- to specify which domain within your AAD tenant the device user objects will be created in
For setup, these are the parameters we must work within. Obviously, if we want to use this solution we must accept the first two requirements. The last requirement is the sole place where we have any real decision within setup.
The AAD user objects created differ from more normal AAD users in our tenant in a couple ways:
- they aren’t created by Azure AD Connect
- because they are not synchronized from our on-premises AD, they have no inherent lifecycle management tied to computer objects there
- their name is in the format “device-<hostname>”
For a variety of reasons, it seems best to segregate these “device users” in a separate domain with no other purpose, perhaps called deviceusers.uw.edu.
Beyond setup, we will have an evergrowing set of AAD users in our tenant, some number of which are unnecessary beyond some point in time. There isn’t really a scalable or fool-proof way for us to gracefully remove those AAD user objects. We might ask customers to let us know, but that doesn’t scale and many
won’t bother. Since there is no automated removal, nor a graceful way for us to remove them, we are left with two general options:
- agree to accept this problem as potential technical debt
- remove objects via an automated process based on some proxy criteria, such as age of the object–and accept unintended impacts as technical debt
It is worth noting that one unintended benefit of these AAD user objects is that our allowed/free number of Azure AD B2B users is increased.
Not putting any lifecycle deprovisioning in place when implementing a new solution is a repeated mistake that often never gets revisited. It is better to put in a less-aggressive deprovisioning solution than no deprovisioning solution at all.
Since we have no real-life experience with these device user objects, there may be criteria we can use which makes more sense and limits the impact.
The following steps are recommended:
- we allow setup of Office ProPlus device user based activation in the UW Azure AD tenant
- we segregate device users to a dedicated domain in our tenant, perhaps called deviceusers.uw.edu
- on a recurring basis, we agree to delete any device user which matches a criteria we determine later
- we give ourselves 3 months to analyze what criteria would be best, defaulting to created more than 5 years ago, if nothing better presents itself
The above recommendation has been proposed. At a minimum, the Azure AD Change Advisory Board needs to review and approve.