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?
Related
Brand new Windows 10 Pro system running 1809. Just installed Access via Office 365 (version 1904). We have a database that was originally created in 1998 and has been updated and working on other Windows 10 systems without a problem. However, when we open it on this new system, we are getting the following error right away:
Compile error. in query expression 'IIf(Hour(Time())<12,"Good Morning",IIf(Hour(Time())>11 And Hour(Time())<18,"Good Afternoon","Good Evening")'
Removing this query does nothing but bring up additional compile errors.
All of the other computers were running Office Pro 2007 at some point - probably when the database was converted from an .MDB to an .accdb file. They are now running the latest version of Access without issue. They all also have an Inactive Application Add-in called "Microsoft Office 2007 Access Database Engine Conflict Resolver" installed and set to Load on Demand. I don't know if this has anything to do with it.
I did install Office 2007 to this computer (Access module only) and that same add-on then appeared in the newer Access. But I have since uninstalled Office 2007 after the issue remained unresolved. (That add-on is now gone.)
My (probably ignorant) guess is that there is old code that isn't being processed correctly and the current batch of computers are handling it via something that was installed during the upgrade process? Our database needs are pretty simple and there are very few users.
Any help in getting this new system into the loop would be appreciated.
Argh. I think the issue was that I installed the 64-bit version of Office 365. All works now under 32-bit. Sorry and thanks.
This is in an Enterprise setup (had a lot of GPO set) running Exchange 2013 Server, with Outlook 2013 client.
I installed the add-in using OWA
Manage Add-ins > Add from file
The add-in appeared in and worked fine
When I open outlook 2013, I do not see the add-in appear, tried a lot of steps to debug.
As per this doc https://learn.microsoft.com/en-us/outlook/add-ins/troubleshoot-outlook-add-in-activation
Version no was ?Session.ExchangeMailboxServerVersion
15.0.1320.4000
Is the add-in disabled?
Enabled
Is the add-in manifest installed properly, and does Outlook have a cached copy?
%LocalAppData%\Microsoft\Office\15.0\WEF \<insert your guid>\<insert base 64 hash>\Manifests\<ManifestID>_<ManifestVersion>
The new added add-in files would get removed everytime the data is pulled from exchange servers. Only 3 default add-in files were available.
Checked Windows Logs in Eventviewer
The Exchange web service request GetAppManifests succeeded.
Got this message with event id 63
We also checked Fiddler and could see the call going to get the manifests but that would give the manifest of only 3 add-ins that come installed by default on Exchange Setup.
For the same account, the add-in works fine in a Virtual Environment, VDI setup. But doesn't appear on the desktop environment, if that helps.
To rule out the possibility of a wrong manifest file, we tried using the Outlook Command Demo Add-in. This also worked on Virtual Environment, VDI setup. But doesn't appear on the desktop environment.
Are there any other steps that can help us debug this? Any directory where logs are available for add-ins?
We have hit a roadblock due to this with no idea how to debug/get it working.
The solution is very simple but impossible.
I have office 2010 and office 2012 installed, VB6 fails to create a Word application object giving me no more than just a message saying that the DLL is not registered.
All attempts to remove and restore the DLL using the installer or third party DLL fails.
After removing everything office related and only installing office 2010, the application object gets created successfully. But this is not a viable solutions for our customers: we can't have them removing their Office suites for this.
Is there any other way?
I had a similar issue on my dev machine with two versions of office. Cast your eye over this article from Microsoft support they mention the /regserver command line option. The article is Office automation when multiple versions of Office are installed. By the looks of it I don't think you can force it to pick one version or the other but the /regserver will help you in your dev environment.
We developed an Outlook Add-In for Win 7 with SP1 and .NET Framework 4.0 as a prerequisite. It gets install perfectly on some machine without any hiccup but in other machines (same configuration, Win 7 & SP1) the add-in goes into the 'inactive' state and doesnt load while outlook start-up.
While installing there are no issues or error message getting displayed. What could be the problem? How can I check or debug what could be causing this issue? Any solution or hints on this will be highly appreaciated.
Inactive add-ins are usually caused by a missing reference that wasn't deployed. Try some of these resources:
http://blogs.msdn.com/b/haahmadi/archive/2010/05/26/my-vsto-add-in-does-not-load.aspx
http://archive.msdn.microsoft.com/vstotroubleshooter
Would need to upgrade the MS Outlook from 2000 to 2010, because the exchange server was upgraded to 2010. I suddenly found that I cannot connect to the exchange server with MS Outlook 2000. I got the admin and he said 2000 are not supported anymore.
We got a program written in VB 6.0 to automate massive(100+) emails sending. The program cooperates with Outlook client and send emails out through the exchange server.
Now I cannot even access the exchange mailbox, so a upgrade is necessary. But I wonder the VB code still valid? Are there compatible?
I have no idea of the detail of the code because it is left by one of our colleagues who had already left the company. There are some .bas .frm .frx .ocx and it cooperates with .mdb file.
According to this Stackoverflow question you will need to change your Outlook object reference to Outlook.Application.14 from Outlook.Application. and of course there may be some other differences in the object models.