Centrally Deploying and Updating the Outlook Add-in

Learn how to choose manifest versions and centrally deploy and update the Outlook Add-in.

Table of Contents

Overview

Outlook Add-in Manifest Distributions

Manifest Distribution: Production Main

Manifest Distribution: Production Fallback

Manifest Distribution: Beta for UAT (User Acceptance Testing)

Outlook Add-in Manifest Flavors

Manifest Flavor: OS.B — On-send, "Block"

Manifest Flavor: SA.SB — Smart Alerts, "Soft Block"

Manifest Flavor: SA.B — Smart Alerts, "Block"

Manifest Flavor Outlook Compatibility Matrix

Recommended Manifest Flavor

Planning Your Deployment

Deployment Methods

Using Entra ID Groups

Deployment Schedule

Locating the Manifest File URL

Centrally Deploying the Outlook Add-in

Centrally Updating an Outlook Add-in Deployment

Updating the Same Manifest

Replacing a Manifest

Confirming (Updates to) Your Deployment

Overview

The Outlook Add-in comes in three manifest distributions, each containing three flavors.

The different manifest distributions are used for the following purposes.

  • Production Main: For end-users, and for POC/trial users (see instructions).
  • Production Fallback: For end-users affected by technical issues (see instructions).
  • Beta for UAT (User Acceptance Testing): For your internal IT team to qualify new versions of the Outlook Add-in in your environment so that issues can be identified and addressed prior to the release of a new version to Production Main (see instructions).

The different manifest flavors offer compatibility with the full spectrum of the latest Outlook desktop and web clients, and deliver on the preferred security posture of your organization (see instructions).

Before deployment, your IT support team should familiarize themselves with troubleshooting steps (see instructions).

To prevent potential email service disruptions, Preava and Microsoft recommend batch deployment of the Outlook Add-in (see instructions).

Outlook Add-in Manifest Distributions

📝 Deploying Multiple Manifests to Individual Users

The Outlook Add-in supports deploying any number of manifest distributions and flavors to a single user.

This allows deploying the Production Fallback distribution (using the 'Optional' method) alongside the Production Main distribution in phase 1 (see instructions).

The Beta for UAT manifest distribution can also be deployed as "Available" alongside the Production Main distribution to your internal IT team (see instructions).

Manifest Distribution: Production Main

The Production Main manifest distribution is intended to be deployed organization wide, and to users participating in a POC/trial.

Manifest Distribution: Production Fallback

⚠️ Lower Availability and Performance

Although it generally has a more stable codebase, the Production Fallback distribution offers lower availability and performance than the Production Main.

There are two primary ways to use the Production Fallback manifest distribution, as outlined below:

  1. Circumventing/Troubleshooting User Issues: If users encounter issues with a manifest release or flavor (e.g., SA.SB), you can switch them to the more stable codebase provided by the Production Fallback distribution. Be sure to report any issues (see instructions).
  2. Experimentation: To test a different manifest flavor (e.g., SA.SB vs. OS.B), you can use the Production Fallback distribution for experimentation. Simultaneous deployments of multiple manifest flavors within the Production Main distribution are also supported.
Deploying a Production Fallback manifest as "Available" to all users before rolling out the Production Main organization-wide (see instructions) allows for faster switching between manifests and may reduce potential user disruption.

Manifest Distribution: Beta for UAT

🔊 Designed for User Acceptance Testing

Deploying the Beta for UAT manifest distribution to your internal IT team is the single best way to preempt issues your users may experience with new versions of the Outlook Add-in.

After passing our internal testing and quality assurances processes, we push pre-production releases to the Beta for UAT (User Acceptance Testing) manifest distribution.

This manifest distribution is for your IT team to qualify new versions in your environment before they get released to Production Main. It helps you identify, report, and resolve issues before a new version reaches all users.

There are numerous ways to utilize the Beta for UAT (User Acceptance Testing) manifest distribution, as outlined below.

  • Deploy as "Optional" to your entire internal IT team along side the Production Main manifest distribution (see instructions). This is the recommended configuration
  • Deploy as "Optional" to select users in your entire internal IT team along side the Production Main manifest distribution (see instructions).

Outlook Add-in Manifest Flavors

 🛑 Warning for Users of Classic Outlook for Windows

Never deploy the SB.SA or SA.B manifest flavors to classic Outlook for Windows users, as they will be blocked from sending emails.

Choosing which manifest flavor(s) to deploy to which users will largely depend on the following factors.

  1. If any of your users actively use or might occasionally use classic Outlook for Windows (see instructions).
  2. Secondarily, your organization's preference regarding permitting or blocking your users from sending unscanned emails if they encounter technical issues attributable to Microsoft or Preava.
    1. Prefer to allow user to be able to send unscanned emails, use the SA.SB manifest flavor (see instructions).
    2. Prefer to block user to be able to send unscanned emails, use the OS.B (see instructions) or SA.B manifest flavors (see instructions).
To learn more about the differences among the manifest flavors please see this Microsoft article.

Manifest Flavor: OS.B — On-send, "Block"

 📝 Most Stable Flavor
This manifest flavor is best supported by Microsoft, mainly because it has been around the longest. However, its functionality is more limited compared to the SA.SB and SA.B manifest flavors.

  • OS.B — On-send, "Block" (see Microsoft article): Emails may be blocked if technical issues attributable to Microsoft or Preava arise. This is the legacy flavor with maximum backward compatibility, particularly with classic Outlook for Windows.

Manifest Flavor: SA.SB — Smart Alerts, "Soft Block"

  • Manifest Flavor: SA.SB — Smart Alerts, "soft block" (see Microsoft article): Emails can be sent under the maximum number of scenarios, especially if technical issues attributable to Microsoft or Preava arise. If an error occurs, users can choose to send an email after a Microsoft-determined timeout (e.g. 5 seconds), effectively bypassing the protection provided by Preava. This flavor also supports Work Offline mode (see Microsoft article).

Manifest Flavor: SA.B — Smart Alerts, "Block"

  • SA.B —  Smart Alerts, "block" (see Microsoft article): Emails may be blocked if technical issues attributable to Microsoft or Preava arise. This flavor also supports Work Offline mode (see Microsoft article).

Manifest Flavor Outlook Compatibility Matrix

The Outlook Add-in flavors (columns) and Outlook client compatibility (rows) are documented in the matrix below.

 

OS.B (On-send, "Block")

SA.SB (Smart Alerts, "soft block") SA.B (Smart Alerts, "block")
Outlook for Windows (classic) yes no no
Outlook for Windows (new) yes yes yes
Outlook for Mac yes yes yes
Outlook on the web yes yes yes

Recommended Manifest Flavor

The recommended manifest flavor is OS.B given it's stable loading performance and backwards compatibility with classic Outlook for Windows.

Planning Your Deployment

Deployment Methods

⚠️ Only Consider Using "Fixed" After Successful Deployment

If you'd like to use the "Fixed (Default)" deployment method, only switch to it no earlier than two weeks after you've successfully deployed the add-in, and no major issues have been reported by users.

There are three different deployment methods offered by Microsoft (see Microsoft article):

  • Fixed (Default): The add-in will be automatically deployed to the assigned users and they will be able to remove it from their ribbon (Outlook client).
  • Available: Users can install the add-in through the Add-in Manager (https://aka.ms/olksideload), and in some cases through the Outlook desktop client directly.
  • Optional: The add-in is deployed automatically to the assigned users, but they can choose to remove it through the Add-in Manager (https://aka.ms/olksideload), and in some cases through the Outlook desktop client directly.

For customers who wish to deploy the same manifest distribution and flavor using multiple deployment methods within a single tenant simultaneously, appending the following to the manifest filename will enable this functionality.

  • Available: Append _optional to the filename (e.g. preava_prevent_os_b.xml becomes preava_prevent_os_b_optional.xml).
  • Optional: Append _available to the filename (e.g. preava_prevent_os_b.xml becomes preava_prevent_os_b_optional.xml).

Using Entra ID Groups

⚠️ Use Entra ID Groups to Manage Users

Use Entra ID groups to manage users, and avoid the "Everyone" option for user assignment during Add-in deployment.

Using Entra ID (security) groups allows seamless integration with your existing user management workflows. Therefore, Preava recommends you configure Entra ID (security) groups based on the manifest distributions (see documentation), as relevant.

  • preava-prevent-users-production-main
  • preava-prevent-users-production-fallback
  • preava-prevent-users-beta-uat

Deployment Schedule


We recommend the following deployment schedule based on the size of your organization.

 

Small

(1-100 users)

Medium

(100-1,000 users)

Large

(1,000-10,000+ users)

POC/Trial Phase

(Week 1-2)

Deploy to internal IT team Deploy to internal IT team Deploy to internal IT team

Phase 1

(Week 3-4)

Deploy to remaining users Deploy to 5-15% of users (early adopters in key regions or departments) Deploy to 5-10% of users (early adopters in key regions or departments)

Phase 2

(Week 5-6)

n/a 20-40% of users (less critical regions or departments) 20-30% (less critical regions or departments)

Phase 3

(Week 7-8)

n/a Deploy to remaining users 30-40% (remaining non-mission-critical regions or departments)

Final Deployment

(Week 9-10)

n/a n/a Deploy to remaining users

Locating the Manifest File URL

  1. Navigate to Admin Dashboard > Integrations (tenant-specific links) and identify the Microsoft Outlook Add-In option.

  2. [LINK TO Outlook Add-in Manifest Flavors] Identify the optimal manifest URL (manifest.xml) file that best meets your requirements (see documentation). If in doubt, use the AWS CloudFront CDN (Production Main) "Preava Prevent OS.B (On-send, Block)" distribution/flavor, as shown in the screenshot below.
  3. Click on the Copy Manifest URL button to copy your manifest file URL of your preferred distribution/flavor to your clipboard to use while centrally deploying (see documentation) or centrally updating (see documentation) the Outlook Add-in.

Centrally Deploying the Outlook Add-in

The video below shows the steps involved in centrally deploying an Outlook Add-in. Step-by-step instructions follow.

  1. Navigate to the Microsoft 365 admin center > (Show all) > Settings > Integrated apps > Add-Ins, as shown in screenshot below.

  2. Click on Deploy Add-In.

  3. Click on Next.

  4. Click Upload custom apps.
  5. Paste the manifest file URL into the manifest URL (see documentation) field and click Upload. Ensure the https:// is not deleted, as this can cause an error.
  6. Specify the Assigned Users, ideally using Entra ID groups (see documentation). Avoid using the "Everyone" option since it limits your ability to easily remove the add-in for specific users experiencing technical issues.
  7. Select your preferred Deployment Method (see documentation).
  8. Click Deploy, Next, and then Close.

Centrally Updating an Outlook Add-in Deployment

Updating the Same Manifest

📝 Old and New Manifests Must Share App IDs

If you are prompted with an error when attempting to update a manifest with a different Application (client) ID / GUID, for example if you are using a different manifest distribution or flavor you will need to replace the add-in (see documentation). 

  1. Navigate to the Microsoft 365 admin center > (Show all) > Settings > Integrated apps > Add-Ins, as shown in screenshot below.

  2. Click on the add-in you wish to update.
  3. After the flyout opens, click Update Add-in, as shown in the screenshot below.
  4. In the manifest URL option, paste the manifest file URL (see documentation) from your clipboard and click Update. Do not delete the proceeding https:// as this may result in an error.
  5. Click Close.

Replacing a Manifest

🛑 Confirm Removal of Old Add-ins Before Deploying Ones

Confirm old add-in manifests have been removed from your tenant and purged from your users' Outlook clients before deploying new ones (typically 6-24 hours, occasionally up to 72 hours).

  1. Remove any old Outlook Add-ins you will be replacing (see documentation), and wait at least 24 hours, as mentioned above.
  2. Deploy the new add-in (see documentation).
  3. After the new add-in has been deployed instruct users restart/refresh their Outlook desktop/web clients.

Confirming (Updates to) Your Deployment

  1. Navigate to https://aka.ms/olksideload to open the Add-Ins for Outlook manager in Outlook on the Web (see Microsoft instructions).
  2. Click Admin-managed.
  3. Confirm the correct Preava Prevent distribution/flavor appears and is "Added," as shown in the screenshot below.