Mac Admin

Migrating Microsoft Office Suite to MAS deployment

Updated 2019.02.01 and 2019.10.02

Hi All, welcome to a new blog series I’m tempted to call “Ben challenged me to…” 😉

In this post, I will outline and provide details of a possible workflow to migrate from your package installed Microsoft Office for Mac Suite Applications, to Mac App Store distribution.


Earlier this month, Microsoft fulfilled a promise made at WWDC 2018 and released the Office Suite on the Mac App Store (MAS)! Ben (aka Mac Mule) covered the release information on his blog here.

Up until now, most Mac Admins have been deploying these Apps from the webpage, either directly or via AutoPKG recipes. In order to switch from these deployed installers to MAS distribution you’ll need to perform a few more steps than just trashing the old Apps and deploying the new ones!

Luckily, the team at Microsoft did an amazing job of documenting the high level steps in order to migrate those users, which can be found here.

Please Note: There are a few assumptions made with this post:

  1. Your users are licensing these Applications by logging into their Office 365 account on launch. The MAS Applications do not (currently?) support volume licensing
  2. You have bought enough Volume Purchase Program (VPP) licenses of each of the Microsoft Office Suite Macs to cover your deployment
  3. You’re familiar with running scripts and deploying MAS Apps via your management platform of choice


Let’s get stuck in!

So the core piece to take away from that KB article is the following action list:

I’m going to break this list down into sections and tackle them one at a time.

Step 1 – Close all Office apps

So, if we’re gonna be removing and redeploying these Apps, we need them not to be open, right?

You’ve a couple of options here, but the simplest is to make sure the user logs out! That way you can run any removals at the Login Window and the Apps should be closed.

Another option could be that you close the Apps for the user but there’s risk of possible data loss depending on how you do this.

Step 2 – Remove the Office apps from the /Applications folder

This one should be easy, right? Simply run a rm -R on the Application bundle.

But, in order to make sure we don’t trash possibly already installed MAS apps, we should also have a check in place. MAS Apps should contain a “_MASReceipt” directory inside the Application bundle (e.g. /Applications/Microsoft

So for this step, and each Application, we should check for the presence of the _MASReceipt directory. If not found, we should be good to trash this.

At this time, the Applications I’ve been considering are:

  • Microsoft Excel
  • Microsoft OneNote
  • Microsoft Outlook
  • Microsoft PowerPoint
  • Microsoft Word

Step 3 – Remove the Office entries from the keychain

Good news and bad news for this step.

Good News: The team at Microsoft already have a script that can clean out the user’s Microsoft-related Keychains. This can be found here.

Bad News: This script works on the user’s keychain and so must be run:

  • When the user is logged in (and the keychain unlocked), and
  • As the logged in user (not as root, so not as a normal Jamf Policy)

The reason for this is that the original Microsoft Office for Mac Apps will add keychain entries linked to their identifier/s. When we remove and redeploy these Apps as MAS, they’ll try to access the same keychain entries but with different identifier/s, promoting the below popups to the end user

These can be a few prompts per App and isn’t a great experience for the end user! By running the NukeOffKeychain script you’ll remove these items from the user’s keychain and the new MAS Apps will create them fresh.

Interesting Note: Paul Bowden posted the below in the #microsoft-office Mac Admins Slack Channel:

So keep an eye out for a possible update to NukeOffKeychain that’s a little less aggressive!

Step 4 – Remove the Office package registrations (pkgutil --forget)

This one is to nicely clean up the receipts left behind by the original installer packages. I mean, if we’re removing what the packages installed, we should really remove the receipts for the packages too.

This can be done via the above command (pkgutil --forget). There are various tools that can be used to figure out the receipts from a package, but as we deployed this via Munki, I pulled the information from there.

The package receipts I’ve considered for this are:


Step 5 – Trigger the MDM server to install the Office apps (such as jamf recon)

This one is a bit easier, once you’ve removed those Apps you can trigger an update in your management system of choice to initiate the installation of the MAS Apps.

For Jamf, you could scope the Apps ahead of time and trigger an Inventory Update (or a recon) to:

  • Update the device record that these Apps are no longer present
  • Trigger an MDM Inventory Update that should start pushing the MAS versions down

Bringing it all together

So, how do we bring this all together?

As part of this work, I wrote a script that can complete steps 2, 4 and 5 above. This can be found here. The list of Microsoft Apps (minus the word “Microsoft”) are loaded in at Line 25, and the full names of the package receipts at Line 28.

My suggested process would be:

  1. Scope the VPP MAS Apps to be deployed to our devices.
  2. Use the script above, triggered at logout / over the login window.
    1. This will remove the non-MAS Microsoft Apps, remove the package receipts and trigger a Jamf Recon
  3. Drop a login script, set to run once per user per device (either via Jamf, outset or a self destructing Launch Agent), that will run the NukeOffKeychain script as the user
  4. In the meantime, the MAS Apps should be pulling down onto the Mac
  5. Grab a tea / coffee / beverage of choice.

Summary and Thanks

There we go. Hopefully this will help you get some ideas on how you can migrate your users to the Microsoft MAS Apps. As always, if you have any questions, queries or comments, let me know below (or @daz_wallace on Mac Admins Slack) and I’ll try to respond to and delve into as many as I can.

I’d also like the thank the team at Microsoft for their efforts to make these processes easier, and suppling helpful (and prompt) documentation!

The usual Disclaimer:

While the author has taken care to provide our readers with accurate information, please use your discretion before acting upon information based on the blog post. I will not compensate you in any way whatsoever if you ever happen to suffer a loss/inconvenience/damage because of/while making use of information in this blog.


After being thrown this little project, wild Microsoft related puns started appearing….


Update 2019.02.01: Adam Codega wrote a great piece on the Why (e.g. why might you switch to MAS App deployment for the Microsoft Office Suite) –

Update 2019.10.02: I meant to add this note a while back but kept forgetting! Paul from Microsoft fame has recommended not to use VPP to deploy the Microsoft Office for Mac Apps unless the user is using an Apple ID:

…this will be the topic of next Tuesday’s video …..bottom line, I’d only recommend MAS if your users have their own Apple ID’s. VPP-based distribution is full of limitations, like the inability to update apps when they are in a launched state – think Outlook, OneDrive (with no user notification, workaround, or otherwise).

…yeah, it stinks, but right now, I can’t look you in the eye and recommend this. Gory details along with RADARs at


2 thoughts on “Migrating Microsoft Office Suite to MAS deployment

  1. Thijs Xhaflaire says:

    Handy EA for reporting and creating groups!



    if [ -d /Applications/”Microsoft ${appTitle}”.app ]
    if [ -d /Applications/”Microsoft ${appTitle}”.app/Contents/_MASReceipt/ ]
    result=”Installed through App Store”
    result=”Installed through CDN”
    result=”Cannot find Microsoft ${appTitle}.app…”

    echo “$result”


  2. Joshua See says:

    Remember that Jamf EAs require a wrapper.

    ls -d /Applications/Microsoft\ [EOPW][noux]*.app/Contents/_MASReceipt 1>/dev/null && echo ‘Mac App Store’ || echo ‘MS CDN’


Comments are closed.