Inconsistencies in Microsoft 365 Licensing for Security and Compliance
Microsoft’s new guidance on licensing for security and compliance begins to remove the confusion around what licenses are needed to use different Microsoft 365 security and compliance functionality. Almost inevitably in a complex area, the guidance creates questions for Office 365 tenants due to some points not been covered and others being unclear.
Coherence and Consistency Needed Across Microsoft 365
Since 2016, Microsoft has released many new security and compliance features for Office 365 and now the wider Microsoft 365 suite. It’s reasonable for Microsoft to recognize their lack of coherence in licensing requirements and attempt to put a framework in place that development groups and customers can work with. Unfortunately, some customers use features today because the lack of precision around licensing led them to believe that plans like Office 365 E3 covered their use.
Microsoft’s warning about licensing is clear:
“Some tenant services are not currently capable of limiting benefits to specific users. Efforts should be taken to limit the service benefits to licensed users. This will help avoid potential service disruption to your organization once targeting capabilities are available.”
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.
No one wants to wake up to discover that users are unable to work because they don’t have licenses to access functionality that previously worked because Microsoft hadn’t implemented code to restrict access to licensed accounts. That’s why Microsoft needs to be crystal-clear about what licenses are needed when.
Automation Versus Manual
Previously, Microsoft seemed to follow the line that the existence of automation or machine learning in a feature created the need for a high-end license. Thus, Office 365 E3 users can manually apply retention or sensitivity labels to items, but if a tenant wanted to deploy auto-label policies, they need Office 365 E5.
Audit events are gathered for all users in the Office 365 audit log and the audit log search is available to search the events, but if you want to automate the process to detect situations like impossible sign-ins (because of distance), E5 is needed to use the analytics available in Office 365 Cloud App Security.
In most instances, the new guidance respects the manual versus automatic demarcation and that’s a perfectly reasonable position to take. Someone’s got to pay for the resources used to process data or develop classifiers through machine learning. Storage is another area where Microsoft incurs costs, which is one of the reasons why advanced auditing demands E5 to store more events for longer (365 days rather than 90 days).
Picking at Some Inconsistencies
Looking through some of the areas covered in the guidance, some inconsistencies and lack of clarity emerge. For example, in Information Governance, which covers retention labels and policies, the guidance says that Office 365 E3 covers a “single organization-wide or location-wide retention policy.” This is the first time I can recall such a restriction, and I am sure it will come as a surprise to tenant administrators who might have multiple org-wide retention policies in place. In fact, there’s no mention of any restriction on E3 tenants using org-wide policies in Microsoft’s documentation.
The new guidance also says that E5 licenses are needed for “importing third-party data through native data connectors.” I think this covers use of the third-party archive connectors used to bring data such as Bloomberg messages into Exchange Online mailboxes, but a lack of clarity exists about what connectors are covered. For instance, does the same apply to the Office connectors used to bring data from third-party sources like RSS feeds or apps like Trello into Office 365 Groups and Teams? Or does it cover importing data like PSTs into Office 365? I can’t find an online definition of what a “native data connector” is in the Microsoft 365 ecosystem.
In the area of eDiscovery, administrators might be surprised to learn that anyone “selected as a data custodian” must have an E5 license. A data custodian is someone who has control over a document or message needed for an eDiscovery case, so including a batch of mailboxes in an eDiscovery case means that all the accounts owning those mailboxes now need E5 licenses.
It’s certainly reasonable to argue that people running eDiscovery cases need E5 licenses if they use Advanced eDiscovery instead of the normal (Core) eDiscovery, but is it reasonable to demand E5 licenses just because a mailbox is scanned or someone wrote a document that’s stored in a SharePoint Online document library?
Another inconsistency is found in Data Loss Prevention, where policies operating against Exchange Online, SharePoint Online, and OneDrive for Business only need E3 licenses while DLP policies for Teams need E5. It’s a mystery why Teams is marked out for special treatment in this area when retention policies for Teams (which are special, because they only process Teams data) are treated in the same way as other retention policies. One reason why the situation might exist is that Microsoft wants customers to move away from DLP checks in Exchange transport rules to use Office 365 DLP policies, and that won’t happen if E5 licenses are required.
Default Retention Labels for SharePoint Online
The PDF accompanying the guidance says that applying a default retention label to a SharePoint Online library, folder, or document set is an E5 feature. I’ve heard people advance the notion that this is an example of automatic processing and therefore warranted an E5 license for any user accessing the library, folder, or set. The idea is laughable because human intervention is needed to assign the default label and no automatic processing or machine learning occurs thereafter. It’s comparable to assigning a retention label to a folder in an Exchange Online mailbox, which is covered by any Exchange Online license.
Underlining the weakness of Microsoft’s position that setting a default label for a SharePoint library constitutes automatic labeling, the labels assigned to documents uploaded to the library (or already in the library when the label is assigned) do not create audit records like assignment of labels manually (by a person) or automatically (by a label policy) do. And because no audit records exist, the label explorer in the compliance center ignores these labels totally. Microsoft needs to look at this scenario and reflect on the reality of what constitutes automatic processing.
Seeking E5 licenses for default retention labels for a SharePoint library reminds me of the verbal gymnastics Microsoft spokespeople used to justify demanding Azure Active Directory Premium licenses for some features used with Office 365 Groups and Teams. That effort didn’t make sense either, except in the confused and sometimes fevered state of conference rooms in the Redmond campus. Microsoft 365 Business Premium tenants now have those licenses bundled into their plan, which is something that Microsoft should do for all Office 365 E3 tenants.
Licensing Shared Mailboxes
Shared mailboxes are often used as repositories for archive information (for instance, a mailbox of an ex-employee is converted to be a shared mailbox to allow continued access to its content). If a document or message needed by an advanced eDiscovery case is in a shared mailbox, does it need to be licensed? The answer isn’t found in Microsoft’s new guidance, but precedent exists for licensing shared mailboxes to use advanced features (like an archive mailbox) and Advanced eDiscovery is called out explicitly in the Exchange Online limits page. All of which goes to show the care which is needed when figuring out licenses.
Microsoft Has Some Work to Do
Hopefully Microsoft will work through and resolve the issues discussed here. The best kind of licensing framework is one that is simple to understand and operate. Maybe that’s a difficult feat to achieve for something like Microsoft 365 when functionality is divided across multiple workloads, packages, and development groups. But it would be nice if some potential angst could be removed for tenant administrators as they struggle to sort out licensing for their organizations.
Using their vaunted telemetry gathered from across cloud apps, Microsoft can calculate a compliance score and a secure score for tenants. It’s surely not beyond the boundaries of possibility to give tenants some insight into their licensing, with or without Clippy’s intervention.