I have found a nice add-in for Word 2013 (VSTO) and I installed it from an admin account, but it doesn't show up in the other local account.
How can I transform the installation for the local user only into installation for all users?
Copy the keys from [HKEY_CURRENT_USER\Software\Microsoft\Office\Word\Addins\YourAddinName] to [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\Word\AddIns\YourAddinName]
Best practice
Ask this question to the developer
Custom Installer
Try Total Uninstaller or my preferred ESET SysInspector which is free
You will take snapshots of PC before and after installing your addin. Then you compare and get the new created files, new registry entries ... then you convert that for ALL USERS and package that in either Windows Installer (WIX or Installshield) either NSIS or a simple Winform program which will work as an installer.
NOTE. I recommend you to contact the addin developer because he is the only one who know what happen during the installation (perhaps also the antivirus :D)
This is a very strange situation that I am in; scratching my head for answers.
I have developed an outlook addin that works perfectly on my dev machine and on about 90 % of the clients machines.
The load behavior of the addin is 3.
On 10% of the users, outlook starts up without loading the addin despite the load behaviour being 3. The user can manually make the addin active by going to the addin manager on outlook but after a restart this addin reverts back to being inactive bbut load behavior never changes from 3.
I used Install Shield LE to package this addin. I don't even know where to debug anymore, I tried changing different load behaviour values but still the same outcome. The addin just won't load on startup with this set of users.
The company uses ZenWorks to automatically install the addin on all the PCs from the MSI i generate using install shield.
One weird thing is, If i go to the installation directory of the addin and install the addin using the .vsto deployment file, it works and gets loaded on outlook (but thats makes it two addins installed).
I also checked the Resiliency section on the registry and the addin isn't there.
I have faced this issue. To solve this, you need to manually delete the registry entries from the following path.
Open registry editor and go to HKEY_CURRENT_USER\Software\Microsoft\Office\Outlook\Addins\<Your add-in> and change the LoadBehavior to 3.
If the above registry entry is not found, then look for HKEY_CURRENT_USER\Software\Wow6432Node\Microsoft\Office\Outlook\Addins\<Your add-in> and change the LoadBehavior to 3.
Go to HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Outlook\Resiliency – remove the REG_BINARY keys found in DisabledItems and CrashingAddinList
where 15.0 is for outlook 2013.
If you are using 2010 outlook, replace 15.0 by 14.0 and for Outlook 2016 replace 15.0 by 16.0
Hope this helps.
After installing all latest windows updates my Excel VBA code is showing an automation error at the very start of the first module. It contains some forms as well as numerous modules of VBA code. However, when removing the forms (and associated code) everything is fine.
The same thing happened about a year ago after some other windows updates. Back then deleting the .exd files did the trick, but the current updates (including Service Pack 3) seem to be different.
What is going on and how can I get the forms to work? All the code is unchanged and has survived all previous windows/office updates. Running Windows 7 (same happening on Vista machine) and Office 2007.
I used to see this a lot with Visual Basic and Crystal Reports; either due to a bad deployment or DLL Hell.
So, my guess is that it's not the code but perhaps some 3rd party controls (OCXs, DLLs) you're using.
Check your References (In VBA IDE, click Tools and References) and to see where each DLL is pointing.
See if any of the dates on the libraries are different than a working machine and you may find the culprit.
Edit
The OP found the problem by following the steps above.
The fix for this particular issue is to unregister mscomctl.ocx:
regsvr32 /u mscomctl.ocx
Then register it:
regsvr32 mscomctl.ocx
Same issue here, problem completely solved after registering mscomctl.ocx!
for Windows 7 or 2008 - remember to run cmd.exe "as administrator", and then:
for 32bit Windows systems:
regsvr32 c:\windows\system32\mscomctl.ocx
for 64bit Windows systems:
regsvr32 c:\windows\syswow64\mscomctl.ocx
Same issue with VBA for AutoCAD. In my case, registering the new mscomctl.ocx with regsvr32 was enough to fix the issue.
We couldn´t solve the problem by re-registering mscomctl.ocx.
But we solved it by removing a "progress bar object form" wich calls mscomctl.ocx... We replaced it with application.statusbar.
Check out http://support.microsoft.com/kb/2687441 for an update that may fix this problem
We have the same problem. In our Add-In, we were able to trace the problem to a declaration of a variable as Excel.Application. The reference to this object is in the Excel.exe file, so it is very unclear as to which files got messed up.
The machines that have this problem were all updated early this morning (15 Aug 2012) with the following updates (sorry for not posting links, as a new user, I'm limited to only two per post):
Security Update for Microsoft Office 2007 suites (KB2596615)
Security Update for Microsoft Office 2007 suites (KB2596754)
Security Update for Microsoft Office 2007 suites (KB2596856)
Security Update for Microsoft Office 2007 suites (KB2687441)
Update for Microsoft Office Outlook 2007 Junk Email Filter (KB2687400)
Windows Malicious Software Removal Tool x64 - August 2012 (KB890830)
At present, we have not found any information on the MSDN site that could clear this up. We're still trying to isolate this down further.
I had the same problem. I got an unspecified error opening excel with my Add-In loading.
In the past, deleting the *.exd files in C:\Documents and Settings\%USERNAME%\Application Data\Microsoft\Forms\
did the trick, but not this time.
When I attempted to open up the forms in my addin, I got a different error and I could not open the forms.
I ended up rolling back to last night prior to the update and everything works again.
Same issue here today after performing the update for Office 2007 Excel. Oddly, one system had no issues despite the update - the newest system. So after some inspection, I noticed this trouble-free system had different version of MSCOMCTL.OCX in windows\sysWOW64 then others. Here are the details of this activeX
Size: 1,070,152 bytes
created: 6/3/2012
modified: 6/6/2012
product version: 6.01.9834
So I copied this to the trouble one and it did the trick.
Also, you might want to check if these application extensions are present in windows\sysWOW64 or windows\system32 for 32-bit system
FM20.DLL (Modified Date: 7/7/2011, version 12.0.6604.1000, 1.13MB)
FM20ENU.DLL (Modified Date: 10/24/2008, version 12.0.6413.1000, 32.3KB)
Not sure where you can download these. I cannibalized them from other systems.
Had the same issue on all of our terminal servers after one of the updates last night. Registering mscomctl.ocx fixed the problem for all users.
Un- and registering the MSCOMCTL.ocx did the trick for me:
Open an administrative-level command prompt. Click START, and type RUN in the run command line. On Windows Vista and Windows 7 you will
see CMD.EXE appear in the quick search list. Right click CMD.EXE and
left click Run As Administrator. A black command prompt opens.
If on a 64-bit machine, type the following: regsvr32.exe /u C:\Windows\SysWOW64\MSCOMCTL.OCX
Hit ENTER then type regsvr32.exe C:\Windows\SysWOW64\MSCOMCTL.OCX
If on a 32-bit machine, type the following: regsvr32.exe /u
C:\Windows\System32\MSCOMCTL.OCX hit ENTER then type
regsvr32.exe C:\Windows\System32\MSCOMCTL.OCX Your Office program
should work again after doing this.
Please see also: http://blogs.technet.com/b/the_microsoft_excel_support_team_blog/archive/2012/08/15/quot-unspecified-automation-error-quot-after-applying-ms12-060.aspx
son of a gun...I re-registered C:\Windows\System32\MSCOMCTL.OCX and everything works again. Thanks so much to all that pointed that out.
I know this has been asked before, but I've never found a solution to this. I created an Addin in Visual Studio for Outlook 2007. I created an Installer and copied the files and created the registry values. It installs perfectly on the developer computer and it uninstalls perfectly as well. But on the second computer, which is also Windows 7 32bit and Office 2007, the registry key LoadBehavior is always reset to 2 when Outlook opens. I edit it to say 3 and it just resets to 2 again. No error message or anything. This also happened on my computer at work.
Now, I did read something about this guy that tried installing Visual Studio on the computer and it would run just fine after. Made me think I need some other .NET library or something?
Why does this happen and has anyone ever found a solution?
In my case this turned out to be caused by an issue in a license protection wrapper from a third-party vendor. The issue has apparently been fixed in more recent versions of that product (contact me in private if you need more details).
Also, watch out for message boxes shown during Outlook startup. Outlook is really sensitive to those and AFAICT it has only gotten worse with Outlook 2010, especially under Windows 7.
Also, see this question of mine for links to a MS blog entry about this.
I have a problem. I've been installing my VSTO Outlook Add-In to the Outlook 2007 on the account that has no security limitations. For the setup, I am using a normal visual studio setup project. I've had the user install few versions of my application before and it worked fine. Recently, I've created a new version of my application (which is installed to HKLM and to HKCU registry (hotfix that allows me to install the add-in to HKLM registry was also installed)). Now the outlook add-in doesn't even load on the user's computer. If you look in Outlook/Trust Center/Add-ins/ you will see my outlook add-in showing up under "Inactive Application Add-ins", but when I try to enable it, I get a message "This add-in is installed for all users on this computer, and can only be connected or disconnected by an administrator" even though I am logged in as administrator. I also looked in the registry and it has LoadBehaviour as 3, which means that it should appear under active add-ins. I tried installing old version, but now it also doesn't work and does not even appear as installed Outlook add-in.
What can be a cause of this problem?
Thank you
I've spent a week on finding a solution and it was so damn simple... the problem was that I've set identical registry settings to HKCU registry and HKLM registry. As a result the registry settings were in conflict, since both HKCU tried to load this add-in and HKLM tried to load this add-in and as a result it didn't allow Outlook Add-In to load at all. As soon as I've got only the HKCU registry setting, my add-in loaded normally. =D
This also happens if you have the InstallAllUsersVisible flag = FALSE in the UI Interface if using an MSI package. Setting it back to the default TRUE fixed this error for me. I had it working using HKCU - but Victor F nailed the source of the issue.