The Issue
As someone whose primary responsibility includes Endpoint Management, I received a question several weeks ago regarding managing Office add-ins on endpoints. Typically, Group Policy and/or Intune controlled this in the past. However, as things have changed with the M365 Apps over the last several years, so has managing the add-ins. Now, managing add-ins is a combination of different solutions if you want to cover all your bases.
Out of the box, Microsoft allows users to browse the Office Store for add-ins freely. With many AI-related add-ins flooding the web store, some organizations have expressed concern over users having open access to the M365 App store and which add-ins they can install. If you fall into that category, you must make some changes, or your users can probably browse and install add-ins freely. As you can see in the screenshot below, almost all the popular new add-ins are AI-related, which are great for productivity but not always great to use (without proper vetting) with sensitive company data.
Types of add-ins
Before we discuss how to manage add-ins, we should clarify some things about Office App add-ins because things have changed over the past few years. Technically, we have two main types of Add-ins for Office Apps: COM Add-ins and Web Add-ins. When it comes to managing web add-ins, Teams and Outlook fall into their own subcategories, but we will get to that later. Let’s briefly describe COM and Web add-ins below, how Outlook and Teams are slightly different from the other apps in the suite, and then review the tools we have to manage the add-ins in your environment.
COM Add-ins
Many of us who have been working in IT for more than a few years think of com add-ins when you hear the term Office add-in. They are only present on M365 desktop apps, typically installed on devices as an MSI/EXE installer, and they’re tied to the machine on which they are installed. Intune and GPO can push these add-ins to devices. They can be used with any of the Office desktop apps, but the most common desktop app to use com add-ins is usually Outlook. Some common examples of COM-Addins are Zoom, ShareFile, or DropBox. One other important note – com add-ins are only compatible with Outlook classic.
Since COM add-ins are not compatible with New Outlook, most vendors are phasing them out and replacing them with web add-ins. However, not all vendors have a replacement yet. For example, the Citrix ShareFile for Outlook add-in states that it is only compatible with Outlook Classic, but a new version is coming soon:
Other vendors, like Zoom, still support their Outlook COM add-in, but are pushing their users to move to the more modern web add-in:
Many organizations are still using COM add-ins, but their time is limited and they will continue to be phased out in favor of modern web add-ins. At this point, you should only use a COM add-in if your third-party app does not have a web add-in available or if specific features are required and only supported in the COM add-in.
Web add-ins
Web add-ins are the new way to add extra functionality to your M365 Applications. Unlike COM add-ins, web add-ins are installed from the add-in store within the M365 App, which is accessible from the app’s ribbon:
Some other differences between web and com add-ins are:
- Web add-ins can be installed and are accessible from both the web and desktop versions of the app. Web add-ins are fully compatible with both the desktop and web versions of the applications
- These add-ins follow the user’s M365 identity, not the device. When a user installs a web add-in, it will automatically appear on any desktop or web app session they use
- Cross-platform compatibility with Mac and some compatibility with mobile apps
- Updates are managed by the vendor and happen automatically when deployed through the Office store or admin center. In contrast, COM add-ins would typically need to be updated with a new package.
For many of the reasons just covered, it’s preferred to use web add-ins where available.
Teams Apps/Add-ins
Technically, the correct term is “Teams Apps,” even though I sometimes hear them referred to as Teams add-ins. These are specific to Microsoft teams and separate from com and web add-ins. Teams is special and gets its own App Store with its own unique apps.
Like web add-ins, Teams apps are accessible on both the web and desktop versions and are tied to the user’s identity. They are also cross-platform for both Mac and Windows and have some functionality (depending on the Teams App) with iOS/Android.
Outlook Apps/Add-Ins
Outlook has also become its own animal regarding add-ins and apps. As we previously mentioned, only Classic Outlook is compatible with COM Add-ins. Both new and classic Outlook contain a new “more apps” button with web apps designed specifically for Outlook.
Managing Add-ins & Apps
Now that we understand the types of Add-ins / Apps that will be used in our environments, we can discuss the different tools we have to manage them.
Managing COM Add-ins (Intune or Office Admin Center)
The best way to manage your COM add-ins is to use Intune. This is for a couple of reasons:
- COM add-ins are almost always deployed as MSI/EXE packages, so these can be easily deployed to your endpoints using Win32 apps
- Since these add-ins have been around since the 1990s, management settings are built into administrative templates, which have been ported over as settings catalog policies in Intune.
We won’t review how to deploy an MSI/EXE com add-in. We are assuming you already know how to do that. To manage which COM add-ins can and can’t be used, you want to make a settings catalog policy and add search for add-ins. You’ll see results for each of the M365 Desktop Applications. In this example, we will focus on Outlook, but you’ll want to add settings for each of the M365 Desktop Apps you want to control. The two settings I want to point out are:
- Block All unmanaged Add-ins
- List of managed add-ins
Check both of those boxes and then click the select all these settings button:
We want to enable blocking all unmanaged add-ins. This will block any add-ins not specifically listed in the List of Managed Add-ins setting. For the add-ins we want to allow, we will need to retrieve that name from the Registry. On a machine with the add-in installed, navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\Outlook\Addins. A list of the add-ins will be under that key. Selecting each key will show you the name value of the add-in, and it won’t always match the parent key. For example, if we want to find the Citrix ShareFile add-in, we can see it’s actually named “Malone.AddinModule”
The name of the parent key is what we need for our policy. Then, we have two options for the value in the policy, to always enable (1) or to allow the user to configure (2). Assuming you want to always enable, the policy should look like this:
Pretty simple. Move through the rest of the policy tabs and assign to your user groups. Once the policy kicks in, you’ll see the whitelisted add-in enabled in Outlook, but any other add-ins that are installed or were previously installed will be automatically disabled. If a user tries to enable additional add-ins from Outlook options, they will be blocked and see a message stating that the add-in has been disabled by your system administrator:
You can get the equivalent functionality using the M365 Apps Admin center (https://config.office.com) and creating a new Policy, then selecting the same options from the list of settings. If we search for “managed” you can see these same settings:
When you create a policy from the M365 Apps Admin center, it can be scoped tenant-wide or to specific users. Personally, I prefer to use Intune for this since that’s likely what you’ll be using to deploy the com add-ins, but this is another option
That wraps up managing COM Add-ins. I won’t go into detail for managing this with GPO since you should be pushing towards cloud-native endpoint management, but the equivalent settings for a GPO can be found under User Configuration > Policies > Administrative Templates > Microsoft Outlook 2016 > Miscellaneous > List of managed add-ins
Managing Web Add-ins
Web add-ins are managed through the M365 admin dashboard and/or the M365 Apps Admin Center. First, lets look at how we can block users from having open access to the web add-in store. The simplest way to do this is in the M365 admin center under settings > org settings > user-owned apps and services. You have the option to disable access to the Office Store, which is a global setting and will apply to all users. Uncheck that box if you want to block this for all users. If you uncheck this box, the store button for the Office Web and Desktop Apps (excluding Outlook and Teams) will be blocked, but you can still centrally deploy add-ins.
This is the easiest way to disable store access, but the downside is that it’s tenant-wide and applies to all users, regardless of other policies. There is a way to scope blocking access, but there are caveats, and it can get messy.
If you want to scope this to certain users, we need to use another option – the M365 apps admin center. You have more granular control over settings in the office apps and can scope these policies to certain groups of users. If you use this method, you’ll want to ensure that office store access is allowed under the M365 admin center under settings > org settings > user-owned apps and services, because now we will control everything using the M365 Apps Admin center. If the setting in User-Owned Apps and Services is blocked, it will override any policies we set in the M365 Apps Admin Center. In Addition, the setting to block the store in the M365 Apps Admin Center will only block it at the desktop app level. It doesn’t apply to the web apps. So, if users figure that out, they can go to the web app and use the store.
I don’t think using these policies for managing access to the store is worthwhile. However, if you wanted to simply block all web add-ins from running in your desktop or web apps, you can make a tenant-wide policy by navigating to Customization > Policy Management and clicking Create. Name the policy and then scope it to all users:
Under Policies, look for these two options: Block the office store and Block web add-ins. Enabling both of these, along with disabling the store from M365 admin center settings > org settings > user owned apps and services, will completely block the store and all web add-ins from running. Even your centrally deployed apps.
Unless you’re in a highly restricted environment, you probably don’t want to blanket block all add-ins. So, my recommendation is to block the store from M365 admin center settings > org settings > user owned apps and services, and then centrally manage the add-ins from the admin center, which we will look at next. Also, when making these policy changes, whether it’s from the M365 admin center or the M365 Apps Admin center, they can take a LONG time before they hit your users. In my testing, it was almost always 24-36 hours for existing devices. Microsoft says it can take up to 72 hours.
The user experience on the desktop apps, for those who are blocked, will be like this for existing web add-ins they had installed:
And if they try to access the store, they will receive a message that the add-in store has been disabled. This screenshot shows two apps under my-addins, which we will get to soon.
The web experience is similar. If users try to launch a web add-in they previously used before the policy:
If they try to access the add-in store:
Outlook is Special
What we just covered works great for Word, Excel, and PowerPoint but not for Outlook. The Outlook Store button is controlled by… well, it doesn’t seem to matter because after days of testing, I could not disable or limit the “More Apps” button. Nor could I prevent users from installing whichever apps they wanted in the Outlook App Store. Blocking access to the store in the org settings had no impact on Outlook (New, Classic, and OWA) accessing the App Store:
Microsoft claims you can prevent users from installing apps using Exchange User Role options. This also did nothing and still allowed full access to the apps button and web app installs:
Another suggestion was to use PowerShell and change the organization configuration to disable AppsForOffice. Again, this had no impact on Outlook or the user’s ability to access the apps button and install web apps:
Another suggestion specific for Outlook Classic was to add the Registry DWORD StoreButtonInRibbonHomeTabAllowed set to 0, stored in HKCU\Software\Microsoft\Office\16.0\Outlook\Options\WebExt. Again, this did nothing.
Another suggestion for Outlook Classic was to disable the store button using the settings catalog in Intune. This showed applied, but again, it still allowed full access to the store button.
So, for now, there does not seem to be a way to block access to the Outlook App Store. If you are looking for a way to block user access and only centrally deploy specific Web add-ins for Outlook, it appears that this is not possible. However, most of these web add-ins require some level of permissions. If your tenant doesn’t allow users to consent to permissions or requires admin approval, they’ll be stopped. You can view the required permissions from the add-in permissions tab:
And if your users can’t consent to permissions, they’ll be stopped from using the web add-in without admin approval
Centralized Deployment
What about web add-ins you want the users to have? We can centrally manage our approved add-ins in the M365 admin center. For the older UI, from https://admin.microsoft.com, navigate to Settings > Integrated Apps, and select the Add-ins link at the top of the page:
This is the older method that is still available, but only supports web add-ins for Excel, Outlook, PowerPoint, and Word:
The rest is simple. Click Deploy Add-in:
Unless you have a custom application, you’ll likely be choosing from the store:
Filter for the App you want to use, then search for your add-in and click add
Select your assignment and click Deploy:
You’ll see a message that this can take up to 12 hours before the app is displayed
After the app is deployed, users can install it from the Admin Managed tab of the Office store. If the app does not appear, they can click Refresh and it should appear.
The more modern method is in the M365 admin center under Settings > Integrated Apps. Select Get apps:
From here, we can see that apps can be deployed to a broader range of apps or services from the available filters:
Locate the app you want to deploy and select it. Select the apps where you want to deploy it:
Scope to your users:
Be aware of the permissions that are granted to the app, and then complete the deployment. The app will then automatically be installed for the targeted users.
Managing Teams Apps
Teams is sort of its own animal since everything is managed in the Teams admin center. Although you can’t completely block the Teams app store, you have more control than you do in Outlook. In the Teams Admin Center, navigate to Teams Apps, then from the actions menu, select Org-wide settings:
Here you can see some toggles for allowing Microsoft, custom, and third-party apps. These are self explanatory. Turn them off if you don’t want users to have free rein over the apps they can install.
After making these changes, users can still browse the Teams app store, but if they try installing an app, they will need to request approval:
These requests go to the Teams admin center where Teams admins can approve/deny the requests under Teams Apps > Manage Apps, and then filter by App Requests.
If there are known apps that users should have access to, you can also make them available to everyone or certain groups of users:
Then select everyone or target your user groups:
Conclusion
Remember to opt for web add-ins in most situations, and I recommend that you require admin consent for any permissions an app is requesting. It’s a good practice and will also help prevent users from using unwanted Outlook web add-ins. Also, remember that Teams is slowly becoming it’s own ecosystyem and you should be managing add-ins in the Teams admin center. Hopefully this post clarified some things and helps with the management of your M365 add-ins 👍