We have a Excel Web Addin, that was deployed to a group of users using the Office 365 Admin Center. But the add-in is not visible in Excel 2016 (Version 1803,Build 9126.2275, Click to Deploy) for those users.
Fiddler trace shows the following when the user tries to refresh the "Admin Managed" add-in dialog box.
Fiddler Trace
<MessageText>User must have a mailbox for name resolution operations.</MessageText>
<ResponseCode>ErrorNameResolutionNoMailbox</ResponseCode>
I also came across this post
"No add-ins currently available." when deploying add-in using Centralized Deployment
that talks about enabling Exchange. I am not sure what that really means.
So any help is appreciated in understanding the issue and resolution.
Thanks
-kudlur
Based on the error message, I'd assume you're having issues with users not being assigned mailboxes, which are required to enable Centralized Deployed add-ins.
Could you try running through the compatibility checking steps outlines here? It will help provide more detail on the exact issue.
Download the compatibility checker here: https://www.microsoft.com/en-us/download/details.aspx?id=55270
Run the compatibility checker Start an elevated PowerShell.exe window.
Run the \Import-Module O365CompatibilityChecker\ command.
Run the \Invoke-CompatibilityCheck\ command, which prompts you for TenantDomain (for example, TailspinToysIncorporated.onmicrosoft.com) and TenantAdmin credentials, and then requests consent.
You can also find more ways to debug in this help article: https://learn.microsoft.com/en-ie/office365/admin/manage/centralized-deployment-of-add-ins?redirectSourcePath=%252farticle%252fDetermine-if-Centralized-Deployment-of-add-ins-works-for-your-Office-365-organization-b4527d49-4073-4b43-8274-31b7a3166f92&view=o365-worldwide#BKMK_UserAndGroupAssignments?omkt=de-CH&ui=de-DE&rs=de-CH&ad=CH
Thanks, Alan
Related
I've been going through the process of submitting a JS based add-in to the Outlook store through Microsoft's Seller Dashboard and I'm receiving the feedback:
Requirement:
Your app or add-in must not stop responding, end unexpectedly, or contain programming errors.
Error:
We encountered an error while testing your add-in.
When authenticating your add-in, we receive an error message and are unable to load your add-in.
Unfortunately there's no other information related to this request making it hard to debug or understand what is happening.
We've tested successfully on Outlook 2016 (Windows 10), Outlook 2016 (Mac OS), outlook.com (on Safari, Chrome, Firefox, and the latest version of IE) and other than a few peculiarities with how the desktop versions of Outlook handle things everything is working.
The only thing I can think of that may be triggering this is that we have a whitelist CORS approach. Currently we've whitelisted the domain our add-in is served from, but if Microsoft is bundling our add-in we'll need to whitelist the location it's eventually served from.
Is it likely that it's a CORS issue?
If so, what domains should we be whitelisting?
If not, how do we debug this given it works on outlook.com, Outlook 2016, and Outlook for MacOS when side loading from the same manifest xml document we're submitting through the seller dashboard?
Unfortunately the Office Store review team will not give many details that could be helpful. You have to provide as much testing information as possible in order for them to succeed. I had a similar loading issue at one point and they did not even bother to provide the browser type or version.
A good strategy is to output as much debugging information as you can to the browser console from your add-in's key functions. If you ask them to provide these logs in your testing notes they may be able to do that for you.
Note that the location your add-in is being served from is always your web server; Microsoft just hosts the manifest for the Office Store.
The error message that the screenshot is illustrating that the webpage your manifest is directing Outlook to load is not available. This means that when Microsoft is attempting to validate the add-in, the web server that the add-in is pointing to is returning a 404 HTTP Response.
I have an Outlook add-in ("Apps for Office" type, i.e. HTML, not VSTO or COM) that is published in the Office store.
Some users have complained that the add-in appears grayed out (GitHub issue). I cannot reproduce the issue on my machine. The "Microsoft Office Alerts" event log on the user's machine shows only "Activated App" events.
How can I diagnose the problem (logging etc)?
Fiddler is usually a good tool for tracing the web requests. Otherwise there are general guidelines for troubleshooting loading issues here: https://dev.office.com/docs/add-ins/testing/testing-and-troubleshooting.
For issues loading your add-in, including run-time logging, see here: https://dev.office.com/docs/add-ins/testing/troubleshoot-manifest
Also check the local cache for the manifest; see: https://dev.office.com/docs/add-ins/outlook/troubleshoot-outlook-add-in-activation
Can anyone please explain why the Office Add-In sub menu appears inconsistent?
The image below shows the dialog displayed after selecting 'Insert', 'My Add-Ins', 'See All'.
The 3 dialogs are from 3 machines that have the same version of Office installed, logged into the same live account and each machine has the same Trusted Location entry https://[???????].sharepoint.com/sites/AppCatalog/.
Yet i get 3 different sub menus. Any ideas?
I assume you refer to the tabs/section inside the dialog? It appears you have 3 different catalogs configured and potentially different identities on each machine. To give you context:
My Add-ins Tab: Shows all the add-ins for your current liveId/individual account.
My Organization: Only appears when you sideload an add-in via a file share. As you point out, via the trusted catalogs section on File>Options>Trust Center>Trusted Catalogs. We should probably rename that tab to "Developer" as reality is that is mostly intended for developers to sideload add-ins for testing purposes.
Office 365: This is the new Centralized Deployment feature that is currently in preview. It only appears when you are signed-in with an organizational account AND the tenant you are connected to supports the feature
Store. Self-explanatory.
So, double check your configuration and make sure to restart the application as configuration changes might not take effect until you do.
thanks for the reply Humberto,
I now have my Add-ins appearing for Desktop Excel.
If I deploy my Add-ins via the Centralized Deployment method, and they appear under 'Office 365' in Desktop Excel, how do i access them in Excel Online? The sub menu only contains 'My AddIns', 'My Organisation' and 'Store'
I have written some code to connect to a SharePoint online server and get a list of *.docx (Microsoft Word) files from a folder on there.
I then display this list of files in a web page and each file is a tag, so that the user can click on it and "open" the file.
When the user clicks on the file, it prompts the user to Open/Save the file (the standard IE/Chrome file open/save dialog). Instead, I want the file to open up in Word Online (in the same/separate browser tab).
I tried searching for possible API support online, but can't seem to find any. SharePoint Online itself seems to be able to do this. If you click on a .docx (or any other Office file), it will open it in Office 365 (provided you have that provisioned).
Any help would be greatly appreciated.
You need to add the appropriate parameters to the link that the user clicks on.
Have a look at an existing document library and see the links that it creates:
https://mytenant.sharepoint.com/_layouts/15/WopiFrame.aspx?sourcedoc={1767368F-62FB-4C40-B3F2-C4EE44E88735}&file=My%20Document.doc&action=default
If the user is not licensed for Office 365, I think that they will still be offered a download. Not entirely sure though as we don't allow that on our tenancy. Certainly if they are only provisioned with SP Online and not the rest of O365, they can view the document online but cannot edit. Though recently we've seen people still able to edit - not yet sure if that is one of Microsoft's secret updates or a mistake by them.
RESPONSES TO COMMENTS:
When I say not provisioned in the rest of O365, I really meant that they were licensed for SharePoint but not anything else (a P2 license rather than an E3), that doesn't give rights to use the online (or iPad) editors. As far as I know, the only real way to test for that is to either try it or to use an Admin account to look at the license.
You cannot "pass credentials" to WOPI since credentials for Office 365 applications come from a separate system. You have to get credentials before you are allowed to access anything in Office 365. Basically Azure AD is the service & the login is done via login.microsoft.com, the login provides a token to your browser that is exchanged with the server on every request. To reuse an existing credential, you have to be using an application that "knows" you have already logged in. Typically, Microsoft use a helper application that picks up the login from IE if that's how you logged in and makes it available to other applications such as Office. If you are using Firefox to log in, IE & Office may not know that you have done so (though there is a plugin for FF that gets installed if you let it which does the same thing).
By the way, if you know how it REALLY works, please don't shoot me down for trying to simplify the process for others. :)
We have a brand new SharePoint 2007 Intranet farm running on new 64-bit hardware with lots of processor and memory. We are using Kerberos for security and have carefully followed all the written guidance from Microsoft and blogs to configuring Kerberos and Excel Services correctly. Generally everything is running great.
Currently we can add Excel Web Access web parts on SharePoint team site pages and connect them up to SQL 2005 Analysis Cubes for use with doing Pivot Tables, Graphs, etc... As part of this, we have created a test dashboard page that has six of these web parts that display upon page load. However we have noticed that we get intermittent errors when a user does things like refresh the connection or workbook, or change the filter on PivotTables. The user gets a generic error messages such as "An error has occurred. Please contact an administrator." and then their session in Excel Services is hosed up. They have to shut down IE and come back to the site in order to interact successfully with the Excel web parts again.
I have looked at the logs but just see generic messages like "EcsSoapException: An error has occurred." that don't give me something that I can really act on. Also I have checked the application event logs but didn't find anything relevant.
Any ideas on how to troubleshoot this?
It turns out this is a bug with Kerberos in Windows 2008. Microsoft has just released a hotfix for this (see link below). The hotfix completely resolved all my issues.
http://support.microsoft.com/kb/969083