The Office add-in that was "enabled by your system administrator" — but disabled anyway.

Microsoft 365 has a safety feature that most administrators never encounter, and most users don't know exists; until it starts disabling business-critical software. It's called Resiliency, and on paper it's a sensible idea. In practice, it can leave you staring at a perfectly configured Office add-in that simply refuses to load, with an error message that reads like a contradiction:

The add-in you have selected is enabled by your system administrator, but it was disabled because it prevented Word from functioning correctly.

We recently worked through this on a client tenant, and the path from "why isn't this loading?" to "here's how to fix it properly" was interesting enough to write up. If you manage Office add-ins on Intune, particularly on Business Premium licensing, this is worth knowing about before it happens to you.

What we were looking at

The specific plugins were were looking at aren't important for this post; they were from a business-critical line-of-business application that installs a set of COM-based add-ins into Word, Outlook and PowerPoint. The issue was that Office had started intermittently disabling these add-ins for non-admin users. Staff could re-enable them from within the application, but the problem kept coming back. On an Intune-managed estate with non-admin users, that's not a sustainable workaround.

The obvious first check is registration and load behaviour. If you're not familiar, Office add-ins live in the registry at:

…with a LoadBehavior value that tells Office when to load them. 3 means "load at startup, currently loaded," which is what you want for anything business-critical. (For context: if you ever see LoadBehavior set to 2, that's Office's way of saying "I tried to load this and it failed, so I've demoted it"; the values are the same for COM and VSTO add-ins, since VSTO sits on top of COM.) We checked, and everything was set correctly. The add-ins were properly registered, LoadBehavior was 3, and on paper there shouldn't have been any issues loading them; however there clearly was.

The diagnostic that actually helped

The thing that unlocked this wasn't a registry search or a policy audit; it was reading the error message carefully. The COM Add-ins dialog in Word doesn't just show you what's installed, it also shows you why something isn't working. And in this case it was telling us, in so many words, that Office had overridden the administrator's configuration on purpose.

That's Resiliency; a feature that's been in Office for a long time, and it does something very specific. If an add-in causes Word (or Outlook, or PowerPoint) to crash, hang or load too slowly, Office remembers and refuses to load it again. The idea is to stop a broken add-in from taking down the whole application every time the user opens a document.

Useful behaviour, in principle. The problem is what it does with that memory.

Where Office stores its grudges

When Resiliency decides an add-in is trouble, it writes to:

…and the value it writes isn't a readable name. It's a binary hash (something like 17EF4E0) derived from the add-in's file path or CLSID. You can't look at it and tell which add-in it refers to without working backwards; and crucially, you can't selectively remove one entry by name. You clear the lot, or you clear nothing.

There are actually three different registry locations doing three different jobs here, and the relationship between them is the part that catches people out.

The Addins\[AddinName]\LoadBehavior key, the one most administrators check first, controls when an add-in loads (3 = at startup, and so on). It's the obvious place to look, and on this client it was set correctly. But here's the thing: if an add-in is on the Resiliency blacklist, LoadBehavior is ignored. It doesn't matter what value you set; the blacklist wins.

Then there's Resiliency\AddinList, which is the registry location that the "List of managed add-ins" policy writes to. According to Microsoft's own documentation, an add-in listed here with a value of 1 "will never be disabled by the Office add-in disabling feature, which disables add-ins for performance, resiliency, or reliability reasons." That's the key sentence: AddinList isn't a "prevent future blacklist entries" mechanism; it's an exemption from the disabling feature altogether. Office checks AddinList before it considers blacklisting an add-in, and if the add-in is exempt, it stays loaded.

So why doesn't applying that policy on its own fix the problem? Because the policy operates prospectively. It tells Office "from now on, leave this add-in alone." It does not retroactively clear DisabledItems. If the add-in was already on the blacklist when the policy was applied, the existing hash in DisabledItems is still there, and Office still consults it on every launch.

This is the trap. You apply the policy, confirm it's deployed, watch the registry show the right values, and conclude you've fixed it. You haven't. You've just stopped the bleeding; the existing blacklist entry is still in force, and the add-in still won't load. You need to do both: configure the exemption and clear the existing blacklist.

How you'd fix this on Enterprise licensing

If you're on Microsoft 365 E3 or E5, the tidy way to handle this is Proactive Remediations (or Remediations, as it's been renamed): a detection script identifies affected devices, a remediation script clears the blacklist, and Intune reports back on which machines were cleaned up. It's the right tool for the job.

Our client wasn't on E3 or E5. They were on Business Premium, which is a perfectly reasonable licensing choice for an SME; but Business Premium gets you Windows Pro, not Windows Enterprise, and Proactive Remediations sit behind the Enterprise feature gate. This is worth being aware of before you design a solution, because it shapes what's available to you.

How you fix it on Business Premium

Business Premium still gives you two relevant tools: Settings Catalog policies (for ADMX-backed configuration) and Platform Scripts (for one-shot PowerShell execution on endpoints). Between them, you can do everything Proactive Remediations would have done; you just lose the nice detect-and-remediate reporting loop.

The solution has two parts, and they need both.

Part one: exempt the add-in from the disabling feature. A Settings Catalog policy using the "List of managed add-ins" setting, with the ProgID of each add-in and a value of 1 (always enabled). This writes to Resiliency\AddinList, which is the location Office checks to decide whether an add-in is exempt from the disabling feature in the first place. With this in place, the add-in won't be added to the blacklist if it misbehaves in future. You do this per application; Word, Outlook and PowerPoint each need their own entry if the add-in targets all three.

Part two: clear the existing blacklist. A Platform Script (PowerShell, run as the logged-on user, 64-bit) that walks the DisabledItems and CrashingAddinList registry keys under the user's Office Resiliency path and removes the non-default values. It's a short script; the tricky part is making sure it runs in user context, because the keys you need to clean are in HKCU, not HKLM. If you run the script as SYSTEM it'll look like it worked and change nothing useful.

Deploy the policy first, then the script. The policy exempts the add-in from being disabled in future, the script clears the existing blacklist entry, and on next launch the add-in loads.

What this is really about

The narrow lesson here is about Office add-in troubleshooting, and if you've landed on this post because you've got a business-critical add-in that won't load, we hope the above saves you an afternoon.

The wider lesson is about how these platforms fit together. Microsoft 365 is a set of products with overlapping configuration surfaces, and the behaviour you observe at the endpoint is the net result of all of them interacting. Group Policy, Intune policy, user settings, and Office's own internal safety mechanisms all have opinions, and those opinions are applied in a specific order that isn't always obvious from the tooling. "The policy is applied" and "the policy is winning" are two different statements.

A few things we took away from this that are worth filing:

• Always check the application's own diagnostic surface first. The COM Add-ins dialog told us what was happening; we just had to read it properly. Plenty of Microsoft applications have similar dialogs that explain themselves if you stop to look.

• Know your licensing before you design. The available management tools on Business Premium are a meaningful subset of what you get on E3/E5, and an Enterprise-centric playbook can quietly fail on SME tenants. Workarounds exist for most things, but you need to know you're looking for one.

• Use "List of managed add-ins" as a matter of course for anything business-critical. It's the one policy that sits above Resiliency, and it costs nothing to configure up front. Adding it reactively, after an add-in has already been blacklisted, is too late.

• Scripts that touch HKCU need to run as the user. Obvious in hindsight; easy to miss in the Intune UI where the default assumption leans the other way.

None of this is exotic. The Resiliency mechanism is documented, the registry paths are documented, and the policy settings are in the Settings Catalog. But the interaction between them is exactly the kind of thing that's hard to spot until you've seen it once; which is the only reason we've written it down.