Outlook Add-in on Exchange 2013: manifest too large - outlook-addin

We have an Outlook add-in using the office.js API 1.3. One user on Exchange 2013 gets the following error when they try to side-load our add-in:
"This app can't be installed. The manifest file for this app is too large. It must be smaller than 32 KB"
We read somewhere a year ago (can no longer find the link) that this was a known issue with Exchange 2013 which would be fixed "soon" in an update. We cannot find an official statement on this issue from Microsoft.
Was this ever fixed? If so, which update is needed to get the fix?
Thanks

Exchange Server 2013 CU14 and above should contain the fix you are looking for.

Related

Outlook addin for web is working on web but not on Office Outlook 2013

It is working on the web but not on the desktop. I have read all the available threads already but I am still not able to figure out the reason
Please guide, any help would be appreciated
My Manifest is compatible with outlook 2013 or later, what can be the reason?
Do you get any errors?
The Troubleshoot user errors with Office Add-ins page describes the information to help resolve common issues that your users or you encounter with an Office Add-in.
You can also use Fiddler to identify and debug issues with your add-ins.

Web Addins on updated outlook client not working, F12 Debugger 'SCRIPT70: Permission denied'

We have developed outlook Addins and hosted on Apache Server with SSL certicate installed with it. Some days back it was working absolutely fine on both web as well office outlook client, after windows update and client update it returns Empty blank screen?
Till the Outlook Client version 1808 all looks good in client. After the Update to outlook client 1902 Addin Stopped working on outlook client.
The error message in F12 Debugger is thrown is :
Everything was working fine before update,
Note that this addin is build on Angular version 5 frame work using routes.
Update: I was loading office.js locally from the project not from the CDN, Now when I changes the office.js path in index.html to the cdn link "https://appsforoffice.microsoft.com/lib/1/hosted/office.js" Addins started working back.
But I need something not from CDN because one of our customer has on-primises server and not the office365 .So the problem I found is the office.js loading the outlook-win32.02.js but saying permision denied if loaded from the project and not from the CDN link.
Hope to get some suggestions from the outlook web addin Team....
After lots of reasearch I decided to use CDN link "https://appsforoffice.microsoft.com/lib/1/hosted/Office.js", and every thing started work as like before,
Then I decided compare my office.js inside the library with the CDN link javascript then I came to know that office script library is updated and I m having an old package, after reseach I found the github project updated recently , the below link will directly takes to the updated libraby , one can download with your existing one,
"https://github.com/OfficeDev/office-js/tree/release/dist" .
Hope this works for all having this issue.

What is the proper flow of updating addin manifest changes for an admin managed addin?

We recently enabled <SupportsPinning> attribute in the manifest of our addin.
Simply pushing our source code to AWS S3 does not update admin managed addins. The work around seemed to be to remove the admin managed addin and then reinstall the addin with the updated manifest.
Is this the correct flow?
Also, while some users are able to see the update (pinnable sidebar), others cannot. Is there some type of cache that can be cleared or an explanation of the inconsistency?
There are 2 questions here.
Question #1 For the admin managed add-ins, should the update flow
happen through the admin portal?
If you are updating the manifest, then the add-in needs to be re-deployed. This is same as the office add-in store as the admin deployments. So you were doing the correct thing.
Question #2 Is there some kind of add-in manifest cache?
Sure - the clients would cache the manifests. Also if the people who are meant to use the add-ins are on different builds of Office, that might create a slight behavioral change as well. It will eventually be updated where eventually is most likely less than 24 hours.

Error while installing the "base" Office 365 Outlook add-in

I created an Outlook add-in using Office developer tools for Visual Studio 2015.
The project is correctly generated, and I deployed it to an azure app service.
When I try to add the add the manifest to my Office 365 dev subscription, I get the following error : "Something went wrong, and we couldn't install your add-in. Please try again later"
This manifest is the exact manifest generated by VS, the only modification was to replace the place holder for the Web URL by the one of the Azure app service.
Has anyone encountered this issue before ?
Thanks.
Can you upload or copy/paste the manifest you are trying?
If you are installing via URL. This is also a common error that is given when OWA cannot download the Manifest from the URL. There could be permissions/something wrong with the URL.
Otherwise, you may also get more detailed information on why the install is failing if you install from the Manage App page instead of the In Client Store Page. (Detailed errors on the In Client Store Page will be added soon)

Automating MS Word in Server 2012 R2

Firstly, please don't reply with the generic advice not to automate Word on a server or a link to the MS web page on "how to automate word on a server if you really must". I am aware of this.
I have a process which runs as a Windows service and uses .Net OLE interop to automate Office (mostly just Open and SaveAs). This code has worked reliably for 8 years on literally hundreds of servers using many combinations of Windows and Office versions, both 32 and 64 bit, so I am happy that the mechanism is reliable. So far...
With Server 2012 R2, it works with PowerPoint and Excel but fails trying to open a word document:
System.Runtime.InteropServices.COMException (0x800A16A0):
The file appears to be corrupted.
at Microsoft.Office.Interop.Word.Documents.Open...
My observations so far which may or may not be relevant:
fails on all documents
works fine in Windows 8.1
the same problem has happened both on a customer site and in our test environment, so is unlikely to be purely environmental
my application is using .Net 3.5
the code is linked against the 2003 Interop assemblies (obviously later office versions are supported by assembly binding redirection)
we have tried it with office 2013 both 32 and 64 bit with the same results, but not tried earlier versions of office
it fails whether the service is running as LocalSystem or as a standard user account
if we run the service process in the foreground (i.e. literally double-clicking on the executable) the problem does not happen
Obviously I still have things to investigate but interested to hear if anyone else has seen this specific problem even if you haven't solved it. Please note there are many difficulties and problems with office automation so unless your symptoms are very similar to mine, you probably don't have the same problem.
Same issues here but got this fully resolved now.
I have a Word 2013 in combination with Windows 2012 R2 Server running in a service process which does everything I want without the need of a interactive session to be started. I use this to convert documents to PDF files. Inside the Windows service I host a WCF service.
Create folders: (replace System32 with Syswow64 depending of you use x86 or x64 bit edition)
C:\Windows\System32\config\systemprofile\AppData\Local\Microsoft\Windows\INetCac‌he
C:\Windows\System32\config\systemprofile\Desktop
Last and most important step!
Start - run - dcomcnfg.exe
Open properties -> Component Services - DCOM Config - Microsoft Word 97 - 2003 Document (Note that the version is not mentioned here but that does not matter Office 2013 will use this as DCOM config)
Open tab Identity. Configure the run as a the local Administrator account. I did some tests Word 2013 will work just fine even if no interactive session is started for the user.
We(My Company) are currently facing the same problem, it is pretty much a carbon copy of your problem. We have completed extensive testing around this area and I am now in talks with MS support engineer trying to find a work around.
Unfortunately this is something they don't want us doing, I think they have tightened security on the Windows Server 2012 to stop people from doing this.
What we have tried which should help you:
Server 2012 | Word 2007 | Failed
Server 2012 | Word 2010 | Failed
Server 2012 | Word 2013 | Failed
Client 8.1 | Word 2013 | Failed
Our problem stems from the fact we are running word with a user who isn't associated with the LOCAL system user(i.e. the type of user you have when you are logged into the machine) Windows will just not allow this to happen anymore.
Myself and the MS Engineer are working on "Fooling" windows into thinking it is running Word as a local service, however the MS Engineer said it was a long shot at best and so far everything we have tried has resulted in failure. It's not looking good.
Sorry I don't have an answer for you, but I suppose its good know you are not alone?
I had the same problem with MsOffice 2010 (32bits) and Windows Server 2012R2 (64bits). Word, Excel, Powerpoint don't work with localAdmin.
I created the folder C:\Windows\System32\config\systemprofile\AppData\Local\Microsoft\Windows\INetCac‌​he like Andy did and it now work perfectly !
Thanks Andy :)
My service use MS Word for data merging and concatenations functions.
I'm using Word 2016 on Windows Server 2012 R2 .
My log says that Word is opened but when the document is opened is throwed an error.
I've first created all the 4 folder suggested:
C:\Windows\System32\config\systemprofile\AppData\Local\Microsoft\Windows\INetCac‌​he
C:\Windows\System32\config\systemprofile\Desktop
C:\Windows\SysWOW64\config\systemprofile\AppData\Local\Microsoft\Windows\INetCac‌​he
C:\Windows\SysWOW64\config\systemprofile\Desktop
Only after creating the last directory the problem was solved.
I've not used DCOM config; my application use an user account with administration priviledges; there was no need to use LocalSystem account with "interaction with desktop" options.
Thank you.
We had a working solution for this for quite some time. However the solution broke when we tried to install it on a fully updated 2012 RTM R2 Server. On a 2016 Server we don't see this issue.
In order to make it work again on Windows 2012 R2 Server and also in a none interactive desktop environment:
Follow these steps!:
Actions to solve the issue on a Windows 2012 Sever R2 which is fully updated by Windows update:
Start - Run - mmc comexp.msc /32
Expand: Component Services – Computers – My Computer – DCOM Config
Search for: Microsoft Word 97 – 2003 Document
RMC – Properties – Go to tab: Identity
Set from “The launching user” to “This user”.
Use a “local Administrator account” which has once singed in to the server machine and has opened Word at least once in an interactive desktop.
Last step: REBOOT THE SERVER! And use a new document name to test your solution again.
Like known and said in the other answers these folder need to be created and accessible by the calling user (local system) normally or the user you configure in the prev steps.
C:\Windows\System32\config\systemprofile\AppData\Local\Microsoft\Windows\INetCac‌he C:\Windows\System32\config\systemprofile\Desktop
C:\Windows\SysWow64\config\systemprofile\AppData\Local\Microsoft\Windows\INetCac‌he C:\Windows\SysWow64\config\systemprofile\Desktop
Thanks for all the help OP and contributors. After creating the INetCache folder it worked out for me. I have done the following to get everything working without an active session(WS2012 R2 / MS Office 2013 64x):
Create a local admin user and log in to setup any printers(printing to file) as well as default word options.
Point the DCOM config identity to the local admin user created.
Create the following file :C:\Windows\SysWOW64\config\systemprofile\AppData\Local\Microsoft\Windows\INetCac‌​he
For some machines you need to run " mmc comexp.msc /32 " to set the DCOM setting for MS Word. I found that we needed to do this when 32 bit version of Word was installed only.
I've just been going nuts to sort this and have tried numerous solutions. I finally resolved this by changing the Identity to "This User". I then used the account that my app pool ran under and also had to add this user the "Administrators" group..
Phew... hope this helps someone too.