Issue
I'm trying to help a customer of ours to install our addin on their Exchange 2013. When they try to add our add-in through EAC it says:
The API version (1.3) required by this app isn't supported by the
Exchange Server version (15.0.1236.3) that you're connecting to
What I've tried
The version number indicates that they are using Exchange Server 2013 CU14.
I've dug through loads and loads of documentation to try to find version of Exchange they need in order to install it. It says in some places that they need Exchange 2013 or later to run addins - which they have.
Questions
What version of exchange is required to run API version 1.3?
What's the easiest way for them to upgrade to that version?
API version 1.3 is supported by Exchange 2016.
Related
I've recently acquired a new client, they are using Microsoft Dynamics CRM 2011 and I need to replicate their working environment on my server.
I seem unable to find a download link for the server setup, the official Microsoft download center gives 404, and all other sources I've found on the web aren't working (the new Partner Center doesn't provide a download for the 2011 version).
Does anyone know where I can find a working installer?
Thanks
We're developing and Outlook web add-in that needs requirement set 1.4, which is supported by both Outlook 2016 CTR and MSI.
We have Outlook 2016 MSI 64-bit installed on 2 different machines. Machine A has Outlook installed long ago and it has windows auto update turned on. Machine B has just had Outlook installed today without any update.
When we tested the add-in on both machine, it's loaded into Outlook of A, but not B. We figured out that Outlook on A is the latest version but Outlook on B is not, so we tried to trigger Windows update on B manually, but it cannot find any update for Outlook. We then tried to download and install the latest update for Outlook from this site, but the result is not as expected:
OUTLOOK.EXE is updated to 16.0.4732.1000, which is the same with
machine A
Outlook > File > Office Account > About Outlook still shows:
16.0.4266.1001, which is different from machine A: 16.0.4639.1000
Requirement Set is updated to 1.3, not 1.4 (we used F12Chooser to
check)
Is there any wrong with our update process? How can we have Outlook on B fully updated just like on machine A?
We recommend getting updates through Microsoft Update since it will update all of the right files.
In your specific case, for Outlook 2016, try also installing this update, which is needed for requirement set 1.4.
I have Exchange on-premises server with version 2013
I wrote an Office add-on which I can install in Office365 account with manifest file with out any issues
But, when I try to install the same add-on from my Exchange 2013 OWA > Settings > Manage Add-ins/Apps it says
This app isn't supported by the version of exchange server that your
account connects to
Searching for this issue showing that the issue might be with the requirement set we use in the manifest. But, I used the same requirement set 1.1 which should support Exchange 2013 as mentioned in the docs.
What else should be done to enable Office add-on in my Exchange 2013?
Any advice/guidance would be greatly appreciated.
#user3752326, I'm glad updating to the latest Exchange 2013 CU solved your installation problem.
The reason why your add-in is not showing up in the side bar is because Exchange 2013 does not support Add-In Commands. Only Exchange 2016 or Office365 support Add-In Commands. Exchange 2013 supports legacy add-ins, which show up in the body of the message, as you have it in your screenshot.
Microsoft publiched the Microsoft Exchange Server MAPI Client and Collaboration Data Objects 1.2.1 at 2011.
Is where are a new version of it?
Is where a another way to work with MS Exchange from desktop without Outlook installed?
1.21 has been the CDO version for the last 15 years or more. It refers to the CDO functionality. It is not a build number.
The version you refer to is 6.5.8244.0. The latest version is 08.03.0.8353.000 released in March 2014: https://www.microsoft.com/en-us/download/details.aspx?id=42040
Keep in mind that it's been on extended support for a while and no changes are expected.
Hi we recently installed an SBS 2011 server for one of our clients and we had some problems using software that creates messages using mapi on exchange 2010. After investigation we found out that the root cause of this problem is that STORE_HTML_OK is not set in the PR_STORE_SUPPORT_MASK.
The weird thing is we (the firm, one of my collegues) did the installation of the sbs 2011 server with exchange 2010 for the client where STORE_HTML_OK is not set, during my investigation of the problem we installed another sbs 2011 server for testing purposes and there STORE_HTML_OK is set whereas it wasn't in the previous installation.
I would like to know what could cause the STORE_HTML flag not to be set in PR_STORE_SUPPORT_MASK on exchange 2010, i also would like to know if we can still change this somehow by changing settings in exchange management console or shell ?
We would like our futurue sbs 2011 servers always to have the STORE_HTML to be set in the PR_STORE_SUPPORT_MASK and like to know what could have caused it not to be set.
Thanks in advance
Willems Davy
EDIT:
Our new sbs 2011 installation has the same problem, i was always testing the code from a client pc where outlook was installed and when outlook is install the mapi version of outlook is used so when running the code from a client with outlook 2007 or even outlook 2003 installed the issue is not there, When installing the mapi runtime (messaging api and datacolaboration objects ...) on SBS2011 the problem is the same (i tested 3 sbs 2011 installations now). The weird thing however is i use the same setup for installing the mapi runtime on a SBS 2008 server and there we don't see this problem, could this be a problem with the mapi runtime being somehow incompatible with sbs2011 / exchange 2010 ?
EDIT2:
we were wrong in our assumption that the STORE_HTML_OK flag was the cause of the program failing, after some more testing it seems this flags is only set when using the mapi dll from outlook, it's never set in our test when looking with MFC_MAPI at the PR_STORE_SUPPORT_MASK on the server when using the mapi runtime not even on SBS 2008.
However the problem with the software is related to the PR_BODY_HTML flag, on exchange 2007 (SBS 2008) servers using the mapi runtime we can change this property on exchange 2010 servers (SBS 2011) we can not and get an error when opening the PR_BODY_HTML propert using openproperty that says "the client operation has failed" this seems to be our main problem and the problem of the software we have.
so it's not related to the PR_STORE_SUPPORT_MASK, maybe i should ask a new question about it, since the problem is not the same as we initally thought?
I don't think this is a server setting. That bit is exposed by the store provider, which runs locally.
What version of MAPI did you install on the machine where your code runs? Is it an older version of Outlook?