Forum Discussion
Office Add-ins error: Cannot connect to catalog
One of our admin-managed add-ins (Adobe Sign) has gone AWOL from the ribbon of the Word desktop app recently (it still shows up in the web-app version of Word). One of the suggested troubleshooting steps is to check review the Office Add-ins from within the app itself. When doing so, I receive an error:
Insert ribbon-->Add-ins section-->My Add-ins-->See all...-->Admin Managed
"Cannot connect to catalog"
I've tried: signing out, back in, clearing the Office cache, and redeploying the add-in from central management. The deployment always reports that it was successful.
Can anyone else reproduce this "Cannot connect to catalog" issue, or suggest additional troubleshooting steps/workarounds?
MTSBob This solved it for me:
Subsequently open Excel, and try going to the managed add-ins. You'll have to reauthenticate (there will be a :warning:sign next to you user account in the top right corner of Excel). A pop-up wizard will mention something about your organization getting access to your device, accept and go through the wizard. Finally refresh the managed add-ins tab and voilà, all add-ins are visible.
The issue only occurred on my specific windows user profile, it never occurred with the same AD user on other machines. (my last option would therefor have been to setup a new windows user profile, luckily that was not needed).I have the same issue for these products of my Office Pro 2021 for Mac Standalone:
Word version 16.71 (23031200)
Excel version 16.71 (23031200)
PowerPoint version 16.71 (23031200)
Outlook and OneNote have their own errors regarding 2016 versions, even though I thought I purchased a Microsoft Office Pro 2021 for Mac Lifetime License (Standalone).
I have an Intel i7 MacBook Pro. The O/S is Monterey 12.6.3. I typically run stand alone.
Who is "ADMIN" that is managing my "installation" (standalone, connect periodically to Internet) other than me?
- Open a terminal window and try the following commands which may be helpful:
defaults write com.microsoft.office OfficeWebAddinDisableAllCatalog -bool FALSE
defaults write com.microsoft.office OfficeWebAddinDisableOMEXCatalog -bool FALSE - We had the same problem in our company and I finally found the cause of our problem today. Some of our users were able to connect, others not. All the users and computers received the same policies etc.
We are busy with migrating our mailboxes form our on prem Exchange servers to Exchange Online. We do this in batches, so some mailboxes are still on prem, some in EXO. Today I found out that the Office add-ins do work for the users with a mailbox in EXO and doesn't work for users with a mailbox in Exchange on prem.
Because we are busy migrating we didn't search for any solution for our users with a mailbox on prem, we just migrate them.
Maybe this info can help some others!- I am having the same problem on a Mac running Ventura 13.1, and the tech support from Microsoft has been horrible. Can anyone here help?
- everyone in my company but me can access Insert > Get Add-ins > Admin Managed except me
- I get "Cannot connect to catalog"
- My computer is online at all times
- My computer is not running a VPN
- My computer is not managed by a centralized security policy
- I have used the Microsoft license removal tool
- I have deleted all Microsoft-related items from Keychain Access
- I have completely uninstalled and re-installed Office more than once
Tech support at Microsoft dodges the issue and avoids the case at all costs.
Any recommendations?- Are the other ones in your company using PC, or Mac? My experience is that this issue is related to Mac, and I have not seen any indication that this feature (Admin Managed Add-ins) works on a Mac.
MTSBob I did have the same problem. My solution was use the same e-mail to login at Microsoft and Mendeley Reference Manager software, your account registered at Mendeley.com should be the same used to log at Word software.
Hi MTSBob - I hope all is well in your world.
I recently encountered this with another "Modern" Office Add-in, one we're in the process of deploying via Trusted Catalogs. What's particularly frustrating is that this was working fine a few weeks ago.
Here's what I think I know:
- The 'Block Web Add-ins' policy is not enabled (set to 0)
- Doesn't seem to matter whether or not the 'Block the Office Store' policy is configured
- The manifest file is in place & accessible
- This was for sure was working in August & July; it's only recently that I've noticed that the add-in is no longer accessible/available.
- Thanks to AGPM I am the gatekeeper for all group policy modifications so I can confirm no rogue changes have been made.
Me and another sharp guy on my team have examined this fully and we're both at a loss. We're beginning to wonder if an update changed this behavior.
- Thanks for confirming and the extra information. This was also working for me up until a few days ago.
MTSBob: We sorted this out today.
- When we were initially manually configuring "Block Web Add-ins" (DisableAllCatalogs) and "Block Office Add-ins" (DisableOMEXCatalogs), we were setting it in HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\WEF\TrustedCatalogs.
- When you configure those two settings in policy (User \ Administrative Templates \ Microsoft Office 2016 \ Security Settings \ Trusts Center \ Trusted Catalogs), it gets written to HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\WEF\TrustedCatalogs.
- Because we need to target this particular Office Add-in to a subset of users, we cannot rely on setting the Trusted Catalog Location policy items so we leveraged registry preferences in order to make use of Item Level Targeting.
When we dropped those keys we matched our initial test configuration which was to write the Office Add-in settings to to HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\WEF\TrustedCatalogs. Turns out that gets ignored or overridden when something is set at the HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\WEF\TrustedCatalogs level. - Once we realized this behavior we corrected the discrepancy and decided to rely solely on registry preferences, not policies, and the add-in started working again.
So we shot ourselves in the foot but it took us a while to realize it.
