We run some custom add-ins in Outlook application and occasionally find that the Outlook application disables them; I then have to manually go to the application settings and re-enable them on each users PC. We are running Microsoft Office 365 click to run applications. I have tried the following but nothing seem to work 100% of the time.
I have tried setting the "AddinList/ProgID" REG key to 1 (always enabled) as described here - https://learn.microsoft.com/en-us/office/vba/outlook/concepts/getting-started/support-for-keeping-add-ins-enabled.
I have also tried setting a number of registry key combinations as described here - https://www.konnectemail.com/prevent-outlook-add-in-from-getting-disabled
Is there a specific way to tell the office application to NEVER disable a particular add-in regardless of the Office version?
Related
I've inherited care for a legacy Outlook add in, triggered by an issue reported by an end-user, stating that the add-in isn't activated anymore.
What I know
We have an old custom add-in:
Written in .NET 4 Client Profile
As a VSTO project
Written in VB.NET
It worked fine on Outlook 2010, the user's recently been updated to 2016.
Symptoms
After installation, loading Outlook takes much longer
You have to manually activate the add-in
If you do, the menu/ribbon is loaded correctly
On shutdown / restart of Outlook, the add in is inactivated again
It's config'd to be x86. I've tried switching that to x64, because I'm on a 64 bit OS, but then the addin just didn't load.
What I've looked into
I've googled a bit and found this link: CRM for Outlook Add-In keeps disabling
I think this quote describes what's going on:
Microsoft has some security measures in place to prevent slow add-ins
from running inside Outlook. The issue is however that in many cases
add-ins without fault are mistakenly marked as slow and disabled by
Outlook, and if this is not immediately corrected when it first
happens, Outlook may permanently disable them with no easy way to
re-enable them.
I've researched with the help of an infrastructure/network engineer colleague to see if we can toggle the add-in to always enable, but no luck.
I've investigated eventviewer logs, I found this:
Outlook loaded the following add-in(s):
...
...
Name: AteamAddin
Description: AteamAddin
ProgID: AteamAddin
GUID: {00000000-0000-0000-0000-000000000000}
Load Behavior: 3
HKLM: 0
Location: file:///C:/Development/Deployment/AteamAddin.vsto
Boot Time (Milliseconds): 328
Followed by an entry with only my add-in on activating in Outlook, but with:
Boot Time (Milliseconds): 172
That's much slower than the second slowest, which loads in 47 milliseconds, but honestly, even 328 milliseconds isn't even that bad for a custom addin.
A weird thing is the empty GUID:
GUID: {00000000-0000-0000-0000-000000000000}
But I don't know if it's important. I've tried adding a Guid attribute to my ThisAddIn class, but no effect.
Question
What can I do to have Outlook 2016 accept the custom add-in?
The load time looks good, I don't see anything strange there. Instead, I'd suggest making sure no exceptions are fired at runtime. Microsoft Office applications can disable VSTO Add-ins that behave unexpectedly. If an application does not load your VSTO Add-in, the application might have hard disabled or soft disabled your VSTO Add-in.
Hard disabling can occur when a VSTO Add-in causes the application to close unexpectedly. It might also occur on your development computer if you stop the debugger while the Startup event handler in your VSTO Add-in is executing.
Soft disabling can occur when a VSTO Add-in produces an error that does not cause the application to unexpectedly close. For example, an application might soft disable a VSTO Add-in if it throws an unhandled exception while the Startup event handler is executing.
When you re-enable a soft-disabled VSTO Add-in, the application immediately attempts to load the VSTO Add-in. If the problem that initially caused the application to soft disable the VSTO Add-in has not been fixed, the application will soft disable the VSTO Add-in again. Read more about that in the How to: Re-enable a VSTO Add-in that has been disabled article.
Also, I'd recommend making sure all the required prerequisites were included to the add-in package.
The application needs two folders to move mails to, so it checks / creates it on startup of the add-in. It looks like Outlook 2016 is more restrictive in what is allowed. Checking these folders likely takes longer than Outlook allows, so the add-in is deactivated.
I moved the checking and creation of these folders to whenever a user opens any of the forms. That way it's way later in the process and that works without issue.
I would appreciate any help as I have exhausted every solution I found at this point.
The Load Behavior of an Outlook Add-In is listed as "Unloaded" under File > Options > Add-Ins > COM Add-ins. It will load and work as expected if I manually check the add in. However it automatically disables when Outlook is restarted. I cannot find a way to make this stick. The following is what I have tried based on Google searches:
The registry shows that all available LoadBehavior options are set to 3, which indicates that it should load automatically. For good measure I searched for every occurrence of "LoadBehavior" to see if I was missing anything, but they are all set to 3.
The "Resiliency" options in the registry called "CrashingAddinList" and "DisabledItems" are empty, indicating that this add-in is not being forced to disable. Again I searched for every occurrence of this in the registry and they look good.
I added a "DoNotDisableAddinList" entry into the resiliency in the registry and gave it a value of 1. This is supposed to load the add-in no matter what.
I uninstalled the add-in, cleared out any reference to it in the registry, rebooted, and reinstalled. The same issue continues.
If I set the user as an administrator on their desktop, the add-in is loaded automatically in Outlook and works as expected. This is the only time it works, however nobody else has this issue and they are not set as administrators on the desktop.
Any ideas?
Thanks
Ian
Looks like your add-in fires an exception at startup...
Microsoft Office applications can disable VSTO Add-ins that behave unexpectedly. If an application does not load your VSTO Add-in, the application might have hard disabled or soft disabled your VSTO Add-in.
Hard disabling can occur when a VSTO Add-in causes the application to close unexpectedly. It might also occur on your development computer if you stop the debugger while the Startup event handler in your VSTO Add-in is executing.
Hard disabled add-ins are listed under the DisabledItems windows registry key.
Soft disabling can occur when a VSTO Add-in produces an error that does not cause the application to unexpectedly close. For example, an application might soft disable a VSTO Add-in if it throws an unhandled exception while the Startup event handler is executing.
When you re-enable a soft-disabled VSTO Add-in, the application immediately attempts to load the VSTO Add-in. If the problem that initially caused the application to soft disable the VSTO Add-in has not been fixed, the application will soft disable the VSTO Add-in again. See How to: Re-enable a VSTO Add-in that has been disabled for more information.
I developed an add-in with a MessageComposeCommandSurface extension point.
It appears, is activated and works on outlook.office.com but with windows desktop client, Outlook 2016 (version 16.0.8625.2121), the button appears in compose mode but stays gray and it is not clickable.
I tested the command-demo-addin mentioned in Microsoft Docs and published on Github with the same result. Similarly, as shown on screenshot, it is impossible to click and launch the add-in which seems unactivated.
The COMPOSE buttons are disabled in the following instances:
1) The Item is in a public folder.
2) The Item is in Junk, Outbox (not drafts), or Sync Issues.
3) The item is "secure". DRM, or S-MIME encrypted. (older versions of Outlook also do not support S-MIME signed)
4) Outlook is offline.
In the situation where Read Mode add-ins are working, but Compose does NOT it is almost always #3. Usually the user will have on the option to always DRM / S-MIME their outgoing messages.
Update with image of security settings:
If Com Add-ins load a Custom Form this can also affect add-ins:
Checking Com Add-ins:
Note that outlook actually ships with some add-ins and a lot of com-addins work fine with Web Add-ins. It's only when Com Add-ins override the default new mail form (or other forms) that they can interfere with Web Add-ins.
Some COM add-ins will NOT use Custom Form, but will access the parent folder (item.Parent) and there is currently a bug that disable's Web Add-ins when a COM Add-in or VBA script does this.
File->Options->Add-Ins-> "Go" (next to manage add-ins)
If you have an antivirus instaled like avast, try to disable the addin of this and then try to open your compose mail window.
I am developing a vsto COM Add-in with form region for Outlook. It works fine. However, I am facing problems disabling the Add-in in Outlook 2010.
From the File Menu > Options > Add-ins > COM Addins (dropdown) , I am unchecking my Add-in. But when I restart Outlook, the add-in is enabled again. If I check in the COM Addins list, its again enabled. Even the registry entries indicate that the Add-in is enabled again. Does anyone know what might have caused this? Can enabling and disabling be handled in my code, or will it be taken care by Outlook itself.?
If the addin is installed in both HKCU and HKLM, make sure you disable it in the HKLM registry hive.
Typically when any changes made in the host application run under regular user privileges are written to the HKCU hive. For example, if the add-in is registed in the HKLM hive any changes in the UI are written to the HKCU hive due to the fact that the host application was not launched with admin privileges (which is required for writing to the HKLM hive). See Registry Entries for Application-Level Add-Ins for more information.
P.S. Try to run Outlook with admin privileges and see the difference.
As it turns out, its is a bug in Office 2010 Professional. To disable the add-in, you need to run Outlook as an admin, and then disable the add-in.
Yesterday I upgraded from win 8.1 to win 10. In Outlook 2013 under win 8.1 I had a VBA script (macro) which was automatically adding BCC to every mail I have sent. This script was digitally signed so that I can have the Macro setting like this: "Notifications for digitally signed macros, all other macros disabled" without asking me to enable this macro every time I start the Outlook. Now it doesn't work any more. The script is working well if I set this macro security setting to: "Enable all macros" - but I don't want to use this setting because of security reasons.
So obviously the problem is somewhere in digital signing of the VBA script. I did it all from the beginning: I removed the previous certificate, created new one using the SELFCERT.EXE, and did all the procedure like with win 8.1 and everything went well like described here except that part in which it should ask only for the first time if I trust the publisher and I should check "always trust macros from this publisher". I cannot invoke this window. Maybe this points out to some problem or inconsistency: it should show this window for me to check it but is not showing because I previously under win 8.1 already have checked it...?
Has anybody some idea how to solve this?
Thanks!
I got it finally!
The only thing I had to do was to run Outlook as administrator. As soon as I did that, the window with "trust all documents from this publisher" appeared and after I clicked it everything after that worked like before.
I had the same issue after upgrading from Windows 7 x32 to Windows 10 but with Outlook 2010 rather than 2013. Tried all sorts of thing without success.
What eventually worked for me was to go into the Trust Center, Macro Settings, and check the box "Apply macro security settings to installed add-ins" as well as the 'Notifications for digitally signed macros' option.
The 'Disable all macros' option gets greyed out.
Click OK and exit Outlook.
Next time you open Outlook you will be asked to accept each of the installed add-ins as well as your self-certified VBA project - but this is a one-time requirement. As belt and braces I allowed it to install the certificates automatically. In my case at least, from then on all my macros ran normally :-)
Hope that helps!
I realize this thread is dated, but I discovered the reason Bzek's solution worked. I don't want to run Outlook as an Administrator, but I also did want my macros to function as they had in W7. The potential solution from Kopweb didn't work for me.
The good news is that a simple check box click in the Advanced section of the Cert properties for 'client authentication' did the trick. Restart Outlook normally and the macros should work. See the image below:
Cert - Advanced Options