Managing Adoption of Office 365 by Controlling Access to Apps

A reader asked me how to limit access to Office 365 services so that their organization can migrate to Exchange Online first, and then gradually adopt more services over a period of time. That’s a reasonable approach to Office 365 adoption, allowing users to adjust to each new feature and receive training, without overwhelming them with the entire suite of apps that are available. Organizations with strict security and compliance requirements need time to examine the different services and work out how to use them in a way that aligns with their organization’s policies. It also allows your IT teams to develop their knowledge and support processes as each feature is adopted by your organization.

To demonstrate how this can be managed let’s start by looking at the Office 365 home page for a user that has been licensed for Enterprise E3. There’s quite a lot of app tiles shown to this user because all licensed features included in E3 are showing up by default.

The visibility or availability of most Office 365 apps is controlled through licensing. To hide most apps from users you can remove those apps, often referred to as sub-SKU features, from the license assignment for the user. You can do this using groups-based licensing, PowerShell, or just do it using the Office 365 admin portal as shown in the screenshot below.

Now the user only sees the licensed features (Exchange Online, and they can also install Office 365 ProPlus), plus the Office Store.

So is it as simple as that? No, not really.

For starters, to get rid of the Store you need to turn it off for all users in Settings, Services & add-ins, and then Office Store.

But that’s not all. Just because apps have been hidden from the home screen of the portal, and from the app launcher menu in the various web interfaces in Office 365, doesn’t mean that your users can’t still use them. Here’s some examples of apps that still work even after you’ve turned off the sub-SKU features in the license controls.

• Forms (currently in preview) allows the user to access the forms app via the direct URL and create forms.
• Stream allows any corporate user to sign up to Stream, upload content, and invite other users.
• StaffHub allow the user to access the app via the direct URL and create teams/schedules, as long as they are permitted to create Groups, and as long as StaffHub is enabled at the tenant/organization level.
• Planner allows the user to access the Planner app to create plans, as long as they are permitted to create Groups, and participate in plans that they are added to.
• Office Online apps are accessible (e.g. creating and editing a Word doc in the web browser).
• SharePoint libraries are accessible via Groups, and SharePoint Online is generally accessible as well.
• Flow allows the user to sign in and create Flows that attach to their Exchange Online mailbox (I did not test access to other services via Flow).
• PowerApps allows the user to sign in and start a trial (I did not test app creation).
• To-Do (currently in preview) is not configurable on a per-user basis and must be turned on or off for the entire tenant. The web app doesn’t support company logins right now anyway, but the mobile apps do, so you might need to look at using MAM policies to control it if that is a concern for you.

Here’s a few apps that do seem to respect the disabled licenses:

• Teams (user sees an “Ask your IT administrator for access to Microsoft Teams” message)
• Sway (user sees a “Please contact your administrator to access Sway” message)

I did not test Skype for Business Online, Yammer, or the use of Azure Rights Management.

There are a few different approaches if you need to make sure your users aren’t using services that you’re not ready to support.

• SharePoint Online access isn’t dependent on a license. You can use permissions to block access if you need to. Disabling the SharePoint Online license for a user does prevent them from using OneDrive for Business though.
• If you want to limit access to SharePoint Online features that are used by Groups, then you should configure your Groups creation policies to prevent users from creating their own Groups. But ultimately if you are going to allow the use of Groups, then users will get access to a SharePoint file storage library for their Groups.
• Planner and StaffHub ignore the license configuration as well, but being Groups-based apps you can use the Groups creation policies to limit their use.
• For StaffHub you can turn it off at the tenant level if you don’t want to use it at all.

Microsoft Stream is a more complicated situation. Any account in your tenant is permitted to sign up for Stream even if the “Stream for Office 365” sub-SKU license is disabled for that user. When they sign up to Stream, a new and separate “Microsoft Stream” license is automatically added to your tenant, and enabled for that user who signed up to Stream. Other users can then sign in to Stream or be invited to participate, even if they do not have a Stream license enabled.

To disable signups to Microsoft Stream you need to block “ad-hoc subscriptions” for your tenant. You can do this by connecting to your tenant with the MSOnline PowerShell module and running the following command:

PS C:\> Set-MsolCompanySettings -AllowAdHocSubscriptions $false

Any subsequent user who tries to sign up or sign in to Microsoft Stream will be blocked, provided you have also disabled their license(s).

However, a user who has already started using Stream will be able to continue accessing it. Removing the licence(s) for Stream does remove the Stream tile from the Office 365 app launcher, but if they know the URL to access the Stream website directly they can just go there and use it. And since they’ve already signed up, the block on ad-hoc subscriptions is too late. So we need to use a different method to limit usage of the Stream service. If you’re doing an evaluation with a subset of your users, use the Stream admin controls to limit who can upload. If you want to block Stream entirely, use the Azure portal to block the Stream application.

Just be aware that the above command to disable ad-hoc subscriptions may prevent your users from using their work email address to sign up for other Microsoft services. Discouraging the use of corporate email for personal services is generally a good practice anyway.

Unfortunately, disabling ad-hoc subscriptions to prevent Stream usage doesn’t block the sign up or usage of Flow and PowerApps. At least not according to my testing. Both of those apps seem to disregard the sub-SKU license configuration for the user, as does the preview of Microsoft Forms. In fact, PowerApps has an FAQ entry stating that admins have no way to prevent corporate users signing up to PowerApps.

Circling back to the original question of how to limit access to apps a part of a controlled adoption process, you can see that it is not as simple as just turning off licenses, even though it should be, and even though that is what Microsoft advises to do in some cases (which then doesn’t work). Yes, by disabling licenses you’ll hide the apps from the app launcher on the web, but if users discover direct URLs for apps they can start using them anyway.

It’s also important to keep in mind that whatever Office 365 adoption controls you do put in place today might be undermined by a future new release, due to the “on by default” nature of new Office 365 features and services. This is all part of the complex and messy reality of managing change in Office 365.