Device-based Office Pro Plus subscriptions

In another example of history repeating itself, Microsoft has revealed plans to introduce device-based subscription for Office 365 Pro Plus. After years and years of evangelizing the benefits of the subscription-based model, which is tied in to the user identify, the powers that be finally caved to the thousands of organizations out there that have users working on shared devices. For the majority of these scenarios, neither the user-based subscription model nor the shared computer activation model worked, so it’s nice to finally see this addressed in a more satisfying manner.

Now, to be fair Microsoft did release a device-based licensing feature a while back, however it was only available for EDU customers and only in the US. In case you have missed the news on that front, you can find some information here. With the new bits, not only Microsoft will expand the scope to the feature beyond just EDU customers in the US, but they will also bring some usability improvements.Ā Most notably “device users” are no more and the feature is controlled based on the device objects themselves, which in turn means you will need to have them represented in Azure AD (either as Azure AD joined or Azure AD Hybrid joined). Yes, that implies Windows 10 devices, and no word so far for support for down-level ones.

To facilitate the device-based licensing model, the Licensing page in the Microsoft 365 Admin Center has been updated to recognize devices as valid objects for licensing, at least when it comes to the Office 365 Pro Plus (device) SKU. Well technically, it will only accept a group that has the devices as its members, not the devices directly. And you seem to be limited to a single group currently. To create the actual group, you will have to leverage the Azure AD portal or PowerShell, as the Microsoft 365 Admin Center still doesn’t support device objects or adding such objects to a group.

On the user front, users will get access to the “standard” desktop apps regardless of their own license. They will get the full functionality of the apps and will also be able to use “connected services” as long as they are logged in with their organizational account. Applications such as Outlook, OneDrive or Teams will of course require users to have a valid account to be configured, and for that the user will require a corresponding, user-level product license. If the user access the device without being logged in with an Azure AD account (as in they are using local account on the device), they will still be able to use the full set of features in the desktop apps, sans the connected/cloud services.

Compared to the good old “Shared computer activation” model, device-based licensing offers few benefits. Those include no limits on the number sign-ins for any given time period, whereas the shared computer activation model was limited to 20 activations per week. It also required the actual user object to have a valid Office Pro Plus license, and in turn a valid Azure AD sign-in. Device-based subscription on the other hand will allow anyone to access the desktop Office apps, regardless of the presence of Azure AD user object or license, as long as they can login to the device itself.

The current expectation is to have this feature broadly available sometime around summer 2020, but plans can of course change. To get some additional details, watch the New and flexible way to use Office 365 ProPlus on your shared devices session. If you want to be a part of the preview, you can submit a request via the following form. The publicly available documentation still only refers to the EDU offering, but can also give you some additional details on how the process will work.

Posted in Office 365 | 1 Comment

Service Health Dashboard improvements and another rant on support

Ignite 2019 is now over and as usual I’ve been spending some time going over sessions I wasn’t able to attend in person. One of these sessions was the “Service Health Dashboard” one, Incident communications at cloud-scale: How Microsoft 365 is improving when things go wrong, presented by Mike Ziock, Sanjoy Ghosh and Sirisha Pingali. This year, there are actually few very nice new features/improvements being released, so I’d say the session is worth watching, but there are a few buts…

Let’s start with the good news. After years and years of leaving the same type of feedback with regards to the ineffectiveness of the SHD, Microsoft has finally released features to address some of the gaps. The biggest one is the “Report an issue” feature, in other words the ability to let Microsoft know you are experiencing some issue with the service by filling a form. Sounds a lot like opening a service request? Yeah, we’ll talk about this in a minute. First, here’s how Report an issue looks like:

So, the idea behind this functionality is that you can send a signal to Microsoft that something is wrong. A signal that contains information relevant to a (potential) outage, gets correlated with similar signals from other customers and (hopefully) ends up routed to the engineering teams much more faster. Because apparently even the SHD folks now agree that the service request experience in the portal sucks (no, they didn’t say that in the session).

If you go over the controls of the Report an issue form, you will see that the selection is very limited and very targeted to outage scenarios. Is it causing impact to your business? You probably wouldn’t be on that page if it wasn’t, but OK. Which service is it affecting, with the choices being Exchange Online, Teams, SharePoint Online, OneDrive for Business and Skype for Business. You can also select Other, which then gives you the option to designate some other services on the next question, including Intune, PowerApps, Flow, PowerBI, the admin center or the SCC.

For each of the individual services/products, you will need to further categorize the issue by selecting from a handful of service-specific scenarios. For example, selecting Exchange Online will result in the following choices: connectivity issues, issues with mail flow, calendaring issues, and other. Selecting Teams will give you a choice of connectivity issues, issues with calls or meetings, issues with chats or presence, or again “other”. Lastly, you are given a free text field where you should provide additional information about the issue, within 1000 chars or less. Pressing the Submit button will then inform you that you will see the issue appear on the SHD within 30 minutes, should Microsoft confirm it’s validity and that it’s affecting your tenant. And, you will also receive an email confirmation. In the future, you will also be able to receive email notifications with regards to the submitted issue’s status updates.

That’s the new Report an issue feature in a nutshell. It’s a good addition, and customer feedback during the preview has been overwhelmingly positive. What’s more important, Microsoft has already validated the usefulness of the feature for the purposes of better scope evaluation and cause determination for emerging issues. And in some cases the feature resulted in the engineering team being alerted even before the internal signals.

To continue with the new stuff, we finally have the option to configure email notifications for incidents. You can configure those by going to the SHD page and clicking the Preferences button on top of the list. Only a single setting is exposed currently, namely Send me email notifications for service health incidents. Some other small additions deserve mention, such as the ability to “confirm” an incident. More specifically, you can click on an a given Advisory and press the Are you experiencing this issue? link to signal Microsoft that their scoping and/or classification of the advisory is incorrect and instead it should be considered an Incident. Another addition should bring “notifications” about current outages as part of the service request submission process.

If all you care about is the new stuff, stop reading here and have a nice day. A small rant will follow, don’t say I didn’t warn you šŸ™‚

So why am I trying to bitch about the Report an issue feature? Because it shows the deeper issue – the disconnect between Microsoft support, as in the vendors they hire to handle support requests, and their engineering teams, the people actually running the service. The above process sound a lot like opening a service request, no? That’s what it is after all, a support request, submitted by a customer experiencing an issue with the service Microsoft is providing, by using the exact same portal you use to submit a “regular” service request. You simply bypass the “helpful” chat bot, “suggestions” and other “AI” gimmicks that have plagued the service request submission process for the past few years, and probably even the first line of support (that part is not confirmed by Microsoft).

A large part of the session was devoted to describing how Microsoft monitors support tickets currently and emphasized the use of ML (of course) and telemetry to identify emerging issues. Signals from other sources are also used, such as internal monitoring probes, the downdetector website, Twitter and more. All good I suppose, but we’ve been hearing this for years and years. Yet, no one I know was happy with the state of the SHD and the accuracy of the information presented there (and the language used, but lets leave that for another rant). Now suddenly a feature that takes into account what customers are reporting as an issue is released and both sides are very happy with it. Why is that?

If support agents actually did a decent job in triaging the tickets, validating issues reported by the customers, communicating back to the submitter and escalating in a timely manner where needed, you wouldn’t need to duplicate the existing “report an issue” functionality. The whole outsourcing model is the problem, and in turn it translates into a people problem. When you outsource your support to organizations that hire the cheapest possible labor, and only care about keeping that contract by any means possible, there’s only so much you can expect. I don’t imagine Microsoft will bring support for their services in-house (they do have the cash for this, mind you), but it’s obvious that the current approach of trying to solve this problem via technology while ignoring the people element aint gonna cut it.

And yes, I do understand (most of) the reasoning behind their approach. I have actually worked as support engineer for Office 365 back when it first GA’d, so I’ve seen the issues from various angles. Supporting such a diverse userbase, ranging from individuals huge enterprises across all industries, and such a huge number of services bundled together is not an easy thing to do. You inevitably get a lot of “how to” tickets, tickets with little to no relevant information, tickets about known issues or ongoing incidents, angry customers who just want to vent, and so on. Many of the support features we’ve seen launched over the past few years have been designed to help reduce the number of tickets, with questionable effect (that’s of course my own opinion). Every little bit helps I suppose, but sometimes something more radical is needed. Hopefully this new feature is an indicator of things slowly moving into the right direction.

Anyway, back to the SHD session. One of the other interesting parts was listening to the questions at the end. Unsurprisingly, many of the same topics that were discussed in sessions from previous years were mentioned again. Which is a very strong “signal” for Microsoft I’d say. Do you know the difference between an incident and advisory? šŸ™‚

Posted in Office 365 | 1 Comment

Azure Cloud Shell is now integrated with the Office 365 Admin Center

Over an year ago, at last Ignite conference, Microsoft previewed an early version of Azure Cloud Shell integrated modules that will make it easier for Office 365 admins to connect to and manage their environments. Now, an year later, this is ready for prime time and it is now actually integrated as part of the Office 365/Microsoft 365 Admin Center:

Now, in my case I’ve already set up Azure Cloud Shell and even played with the installed modules a bit. If you haven’t done so already, you will have to go over the provisioning process, including creating an Azure subscription, in order to use the feature. Once you go over all that, you will have access to the Azure, AzureAD and Exchange Online cmdlets straight from your Office 365 Admin Center. And yes, it’s only available from the Office 365 Admin Center for now, and of course via the Azure portal as well.

I’ve covered this topic extensively in a review of PowerShell Web Access methods over at Practical 365 and more recently when the EXOPSSessionConnector module become available in Azure Cloud Shell back in May 2019, so I will not go into any additional details here. Check the above articles if you are interested.

Posted in Office 365, PowerShell | Leave a comment

Office 365 admins need no help (pane)

Over the past few months, Microsoft has been rolling out some updates on the help pane across different Office 365 workloads. The pane now gives you some contextual recommendations and suggestions around the top issues you might encounter, as well as search functionality powered by the results from support.office.com. Or at least that’s the theory.

As the first and most obvious example, you can try navigating to any page inside the Office 365 Admin Center, then hit the help button there. Instead of actually seeing the help pane, you will be presented with the “vastly improved” service requests pane. Makes sense I suppose, as an admin user you shouldn’t really need help, and when you do need it, you obviously must contact the support agents. And since being able to access the support requests pane is tied in to you having the corresponding roles assigned, guess what happens when you open the portal as a user with some limited role, say a Security Reader, and hit that button. Why nothing of course, you can press and press it how many times you like, and it will not result in anything.

Actually, the above is not entirely true. If you open the admin center via the https://admin.microsoft.com link and stay on the landing page, hitting the help button will actually bring the help pane, along with the Custom help desk info. If you however navigate to any other page within the admin center, including returning to the landing page, hitting the button will result in displaying the service requests pane. Always nice to have uniform experience! Luckily, the Help pane will stay open while you navigate between pages, unless you decide to close it. Which in turn you should do by pressing the “x” button on top, as pressing the “?” (Help) button will toggle the service requests pane once you navigate away from the landing page.

Within other administrative endpoints, such as the EAC or the Teams Admin Center, the help button works as expected, but the actual “recommendations” presented there include things like “Install Office”, “Where’s my app” or “Give Office 365 a try”. That last one is a hoot! Overall, the Office 365 Admin Center is the only one that gets any in-context content displayed on the Help pane, if you can even see the Help pane that is. On the positive side, at least they didn’t remove the “Show cmdlet logging” option from within the EAC, which is still accessible by pressing the Help button on top.

As a side effect to all this, Office 365 Global admins will have to deal with slight inconveniences when working with the Custom help desk functionality, as they simply cannot preview the changes they make from within the Office 365 Admin Center. Navigating to any other admin portal or web app should expose the changes though, although I would really recommend that you do so in a private session as there seems to be a lot of caching being done and no matter how many times I try to refresh OWA, my GA account never sees the custom help desk info exposed within the Help pane therein.

Posted in Office 365 | Leave a comment

Managing Azure AD Administrative Units via the Graph API

While browsing the Graph API documentation earlier today, I spotted a new addition to the \beta APIs – endpoints to manage Azure AD administrative units. For those of you that aren’t aware of AUs, here’s the one-minute version: AUs are “containers” for user and group objects, which you can then use in order to delegate someone control over said objects. For example, you can delegate permissions for Admin1 to manage all objects inside AU1.

Simple. And very limited. And overlooked for years. AUs first appeared in 2015, and I covered them in this article. Nothing changed for few years, until 2018 when Microsoft finally added support for AUs for the Office 365 Admin Center, as detailed in this article. Now, we get to manage those via the Graph API as well, which hopefully means AUs will finally get some love and be made more useful, or maybe even better – we might get full-fledged RBAC controls for Azure AD.

Anyway, to the subject at hand. You can use the /beta/administrativeUnits endpoint to list all AUs created in the tenant. To get the properties of a specific AU, use the /beta/administrativeUnits/{id} one, as shown below:

Looking at the output, we can spot a new property listed, namely visibility. This property is not available via the MSOnline AU cmdlets, nor the Azure AD ones, and serves to limit visibility of the AU members. Here’s the description straight from the documentation:

Controls whether the adminstrative unit and its members are hidden or public. Can be set to HiddenMembership or Public. If not set, default behavior is Public. When set to HiddenMembership, only members of the administrative unit can list other members of the adminstrative unit.

To test this new property, we will create a new AU, using the Graph API explorer. In order to do so however, we first need to make sure permission requirements are met, meaning add the Directory.AccessAsUser.All scope (alternatively you can use the AdministrativeUnit.ReadWrite.All scope, but that’s not available for selection in the Graph explorer, so you will have to add it by other methods). Once we have sufficient permissions, we can execute the request:

After running the request, I noticed I made a small typo in the description field, which we can easily remedy with a PATCH operation. Next, we want to add some members to the AU, which unfortunately can be done one object at a time only. This is done by calling the corresponding /beta/administrativeUnits/18560689-d221-4f88-a713-17e973cf6498/members/$ref endpoint.

Once we have added a member to this AU, we can explore how the visibility setting is affecting it. If we try to list the members of this AU with a Global admin account, we can still see all its members, which I’d wager is the expected behavior. If we use a scoped-role user, such as the ones you’d assign to manage other AUs, the membership will return empty. This is illustrated on the screenshot below, where the first user cannot see members of the AU, while my GA account can see members of the same AU just fine:

Other than that, managing AUs remains pretty much the same. We still can only assign either the User account administratorĀ or theĀ Helpdesk administratorĀ roles, so not much flexibility there. Still no way to dynamically add members, and as mentioned above you can only add them one at a time.

Posted in Azure AD, Graph API | Leave a comment