Every once in a while, a feature makes it to General Availability only to be pulled back soon after. The question always lingers: why did it go? Was it incompatible with some other feature? Did it expose a weakness? Was it just under-utilized? Sometimes we don’t really notice the withdrawn feature, or it comes back later as part of another product.
Pressing for an explanation rarely yields fruit, but sometimes we get a detailed explanation, like when Microsoft withdrew support for pre-population of the username field in AutoPilot Pre-Provisioning (https://techcommunity.microsoft.com/t5/intune-customer-success/updates-to-the-windows-autopilot-sign-in-and-deployment/ba-p/2848452).
Last week we saw the announcement that Microsoft will change Windows 365 Enterprise licensing behavior to include provisioned devices in grace period as part of the total license count. So far I’ve seen this announcement in two separate places, but neither offered the sort of insights that would explain such a change.
Dropping “grace period” devices from the license count is important in license flexibility. A company with 20 licenses, for example, can quickly recycle a license for employee turn-over without buying a 21st license when a new employee is onboarded. When the old employee is removed from the provisioning policy or license group, that Windows 365 device enters a 7-day grace period during which it is neither deprovisioned nor stopped. That license can be immediately re-assigned and the new user is generally up & running within 20 – 30 minutes.
Grace period can also be canceled for a device, so that it is immediately stopped and deprovisioned, but that’s not a default behavior. With the new licensing behavior, that same company would now need to temporarily increase their license count to 21 or manually end the grace period.
So why the change? I’m going to guess it was unintended usage of the grace period behavior.
Much like Exchange users of yore who used the Trash folder to evade quotas, the grace period could allow companies to take 2 or 3 sets of non-overlapping shift workers and assign Windows 365 licenses to each shift, then automate the rotation of those licenses to the next set of shift workers. Done “properly,” and with the right set of Conditional Access policies, this would actually be a pretty clever way to ensure shift workers don’t log hours outside their assigned shifts: the environment simply doesn’t exist for them at any other time of day. It would also be one of only a few possible ways to time-bound access to cloud resources. And because the user isn’t even logged off during the grace period, the environment would remain persistent from shift to shift, license-allocation to license-allocation.
If this sounds familiar, I’d urge you to look at Azure Virtual Desktop. Windows 365 is a phenomenal product for delivering a persistent experience accessible from anywhere, but Azure Virtual Desktop offers a nearly identical set of capabilities with much greater configurability. Azure Virtual Desktop, for instance, can leverage Reserved Instances to reduce the compute cost by up to 80% when coupled with hybrid OS benefits, and administrators can deliver the same persistent desktop experience to both Active Directory users and now native Azure AD users. There is more complexity, but in an environment that’s already considering license rotation, it’s complexity that’s already present.
That’s one playbook, and it’s honestly the one I hope they’re fixing, because the other one—the one I thought of first when reading the announcements—is potentially more nefarious. We’ve already addressed the fact that the unassigned user isn’t even logged off the machine during the 7 days of grace period. That’s a long time to use a lot of processing power without a license, and that license doesn’t have to exist for long to kick the grace period out another 7 days. What if Power Automate, instead of rolling through 3 groups of 20 users, rolled through THOUSANDS of users? What if it did that with only a handful of licenses, such that 6 licenses were enough to float 1000 machines each being licensed for about an hour a week (the math roughly works out for that)? Sessions and active processes would never end, and because the licenses are fixed cost and the resources run in Microsoft’s own Azure environment, there would be no additional costs incurred: just the monthly run-rate for those 6 licenses.
Obviously that’s a worst-case scenario, and you wouldn’t be alone to think “crypto-mining,” but I have talked with developers who need spot instances of compute and who aren’t concerned with licensing constraints or don’t know all the options available to provision cloud compute power. This deployment scenario would seem pretty ideal.
It may also help to explain why I saw a flurry of targeted advertising for Azure “spot VM’s” over the past few weeks. If you’re not familiar with the idea, spot computing is unused capacity in existing datacenters that can be purchased for steep discounts to perform interruptible tasks. The Azure solution also supports setting maximum pricing for a given workload, along with cost management and performance history. Spot VM’s can run any supported Azure VM size, too, with costs averaging 80% lower than their normal run-rate, even for the big machines. Organizations that are drawn to the simplicity of Windows 365 for transient workloads should strongly consider leveraging Spot VM’s.
In addition to the options above, the deployment of Spot VM’s is also subjected to a tenant’s Azure Blueprint policies, allowing tenant-, subscription-, or resource-group-wide compliance controls, and Microsoft Defender for Cloud customers gain the benefit of automatic enrollment of all subscription devices into Defender for Endpoint.
Would you like to find out more about Windows 365? Learn how you can deploy Windows 365 today.