A kind reader asked me if I knew of a way to reset or reinstall the MAPIoverHTTP protocol for Exchange 2016. Although there are ways to reset MAIPoverHTTP, it is questionable whether this would have helped in this case. So here is a little story about the compatibility of Trend Micro Worry Free(!?) 9 and Exchange 2016. Silke has kindly allowed me to publish the information here so that no more admins run into this problem. Thank you Silke!
So here is the e-mail from Silke:
Short version
When installing the Messaging Server Agent from Trend Micro Worry Free Business Security 9.0 SP2 on a Windows Server 2012 R2 with Exchange 2016, MAPI is irreparably destroyed.
Long version
I'm about to hit the 75 limit of my SBS 2011 Premium (Server 2008 R2 with Exchange 2010 and dedicated SQL server), and apart from that, the thing finally has to go. So I'm moving the entire system to several Server 2012 R2 and the corresponding current versions of Exchange and SQL. Server and SQL are ready, now it's Exchange's turn.
So I installed Windows Server 2012 R2 on a new machine, joined it to the domain and installed Exchange 2016 on the pristine white server. Then I completely configured and tested it and moved the users. All good, access via Outlook, OWA and ECP without any problems.
Before I move the reception to the new server, I should put a virus scanner on it... I thought to myself . The system is running Trend Micro Worry Free Business Security (TM WFBS) 9.0 (current patch level). In addition to the security agents for the desktops and servers, WFBS also has a messaging security agent for Exchange Server. This is installed by adding the new Exchange to the WFBS administration console.
Immediately after installation, my Outlook clients (2010 and 2016) could no longer connect. A new profile failed because the Exchange was supposedly no longer accessible, OWA and ECP continued to work without any problems. So I first familiarized all affected users with OWA and then contacted Trend Micro and MS.
Here are the relevant answers:
Answer Trend Micro
Dear User
First of all, let me just provide you this information. Upon checking, looks like the Messaging Security Agent is not compatible with Exchange 2016. I believe that's why the Exchange 2016 configuration was broken or not working anymore. Unfortunately, here's the only possible solution that I can think of for this concern.
Make sure there are no more remnants of the MSA on the machine:
Refer to this helpful article for manual removal.
http://esupport.trendmicro.com/solution/en-US/1096694.aspx
Once done, you can try to check out this article from Microsoft on how to configure the MAPI over HTTP as they've mentioned to you.
https://technet.microsoft.com/en-us/library/mt634322(v=exchg.160).aspx
To tell you the truth, I'm not really familiar with this function itself from Microsoft so if you need assistance on this, you can refer to them instead.
Lastly, if all else fails, I believe we might resort to the re-installation of the Exchange as the Microsoft support suggested.
*Additional note: If you want protection for your Exchange 2016, you can try our Scanmail for Exchange (SMEX) instead.
Hope this answers your concern.
Let us know the results.
Thank you and have a good day!
Answer Microsoft
This is a known issue which can be reproduced on Exchange 2016 Servers.
The installation of the TrendMicro application breaks the MAPI over HTTP protocol on the Exchange 2016 servers.
The only known workaround to the problem is an installation of a new Exchange 2016 server.
The problem arises because of the use of a third party Application and is thus not supported from Microsoft perspective.
End
At this point, no further attempt was made to bring MAPIoverHTTP back to life. Who knows what kind of rotten eggs have been laid in the nest. Reinstalling is probably the easier way here. I didn't find any information on the Trend Micro website that Worry Free (nice name in this context) is already compatible with Exchange 2016. The system requirements manual only mentions Exchange 2013, but that doesn't seem to have been updated for some time, as the SP for Exchange 2013 is still listed as N/A:
Virus scanners in particular often cause problems on Exchange servers, so it is essential to ensure compatibility beforehand. The corresponding exclusions must also be configured:
https://technet.microsoft.com/en-us/library/bb332342(v=exchg.160).aspx
If you know of any such stories, please feel free to send them to me. I always find it helpful to hear about such problems in advance :-)
Many thanks at this point once again to Silke, who agreed to the publication.
I would even go so far as to say that there is no need to install a virus scanner on Exchange servers, but that a slightly different concept leads to more success and fewer problems:
What do you think? Feel free to write your opinions in the comments.
Hallo Erich.
Danke für Deinen Hinweis – aber durch fehlende Punkte im Satz an entscheidenden Stellen habe eine kurze Frage. ^^
Ich zitiere Deine Aussage: „Exchange 2016 CU6 Update auf CU7 Net4.6, 4.7 deinstalliert und per Registry geblockt“
Soweit verstanden, aber hast das CU7 neben .net 4.6 und .net 4.7 auch deinstalliert und geblockt, oder läuft Dein Exchange 2016 mit CU7 (ohne die aktuellen .net Versionen)?
Also so: „Exchange 2016 CU6 Update auf CU7. Dann Net4.6, 4.7 deinstalliert und per Registry geblockt“
:=)
Bisher eingerichtet: Windows Server 2016 Std. (aktuell gepatcht), Exchange Server Std. CU7. Und noch *kein* .net 4.6 und/oder .net 4.7 auf dem System.
Es steht an: SMEX Komponente des WFBS 9.0 SP3…
Auch meinen Dank an Franky für die wirklich informative Webseite – und natürlich an alle User, die ihre Erfahrungen hier teilen!!
Gruß, MaGGs
Hallo MaGGs,
zuerst Server 2016 installiert, dann net 4.7 deinstalliert, da automatisch reingerutscht.
Dann Exchange 2016 CU6 mit Net 4.6 und TrendMicro WFB 9.5. Danach CU7 installiert. Alles ok.
9.0 SP3 ist lt. TM nicht kompatibel zu Exchange 2016.
Gruß
Erich
Hallo in die Runde,
hier noch ein Nachtrag:
Exchange 2016 CU6 Update auf CU7 Net4.6, 4.7 deinstalliert und per Registry geblockt, TrendMicro WF Adv. 9.5 läuft alles, Win7/Win10 mit Outlook 2013/2016.
Hatte vorher auch ausgiebig mit der TM Hotline Telefoniert wegen 9.3 / 9.5.
Kann ich nächste Woche ausliefern :-)
Vorher lag es an der Internetverbindung in meiner Testumgebung. Komisch, daß Win7 funktionierte und Win10 nicht.
Vielen Dank an Frank für die tolle Seite und an alle User.
Viele Grüße
Erich
Ich habe Exchange 2016 CU7 auf Server 2016 und Trendmicro 9.5 im Einsatz, Windows 7 funktioniert mit Office2016 und Office2013 , Windows 10 findet Outlook den Exchange Server nicht (keine Anmeldeserver verfügbar)
Die Module CGI und FastCGI habe ich im IIS nicht. Wurden in der Standardinstallation nicht installiert.
Sollte ich nachinstallieren?
Lt. TM soll 9.5 den Exchange unterstützen.
Wir haben derzeit TrendMicro 9.5 und Exchange 2016 im Einsatz. Bisher keine Probleme erkennbar.
Offiziell wird es nun unterstützt,
in „klinischer“ Umgebung lies sich der Agent auch schon auf einem Exchange 2016 installieren.
Praxistest steht noch aus.
Melde mich sobald wir hier Erfahrungen gesammelt haben.
Hallo zusammen,
hat jemand erfahrung mit Trendmicro WFBS 9.5 und Exchange 2016 gemacht?
wir hätten das bei zwei Kunden im einsatz, bzw. das Update steht an.
mfg
Ok,
Super vielen Dank!
Outlook läuft wieder, MSA ist noch deinstalliert, der Kunde soll jetzt erstmal wieder arbeiten. Werde das heute Abend nochmals testen und dann berichten. WFBS ist eine abgespeckte Version vom OfficeScan, SMEX taucht im IIS ja auf.
Das klingt ja toll,
Und das entsperren der Module hat den gewünschten Erfolg gebracht?
Der Artikel von Trendmicro bezieht sich ja auf SMEX und nicht auf WFBS,oder?
SMEX soll ja offiziell Exchange 2016 unterstützen..
Ich hab das gleiche Problem. Laut Support von TM: Exchange 2016 wird nicht unterstützt, die Deinstallation vom MSA sollte das Problem beheben –> tut es aber nicht.
Nach langer Recherche bin ich auf diesen Link gestoßen: http://esupport.trendmicro.com/solution/en-US/1113591.aspx
Im IIS unter Module CGI & FastCGIModule entsperren. Dann Outlook an den Clients neustarten. Und siehe da, Verbindung funktioniert wieder.
Hallo zusammen,
wir setzen auch Trendmicro WFBS 9.0 mit SP3 ein und planen eine Migration von Exchange 2010 auf 2016!
Der Support von Trendmicro selbst schweigt bis jetzt.
Hat schon jmd Erfahrungen mit dem SP3 und Exchange 2016 gemacht?
Mittlerweile gibt es ja das SP3 vom TM WFBS 9.0… da steht auch drin:
„Problem 9: ActiveSync funktioniert nicht, wenn das Feld für die HTTP-Autorisierungskopfzeile keine Benutzerinformationen enthält.
Lösung 9: [Hotfix: MSA 11.1.1306] Dieser Hotfix ermöglicht Worry-Free Business Security die automatische Erfassung von Benutzerinformationen, falls das Feld für die HTTP-Autorisierungskopfzeile keine Benutzerinformationen enthält. Dadurch wird sichergestellt, dass ActiveSync ordnungsgemäß ausgeführt wird.
Mit diesem Hotfix werden auch Probleme im Zusammenhang mit der Benutzeroberfläche von Messaging Security Agent behoben. Nachdem dieser Hotfix angewendet wurde, öffnet Worry-Free Business Security die MSA-Webkonsole auf einer neuen Registerkarte in Internet Explorer.“
Hat hier schon jemand testen können ob das Problem mit dem SP3 noch auftaucht?
Mit Entfernung der VSAPI aus Exchange 2016 ist ein AddOn Virenscanner auf dem Exchange relativ sinnlos, da der Information Store nicht mehr „on the fly“ überprüft werden kann…
Der integrierte Virenscanner ist, wie in Windows 10, für das Gröbste OK. Ankommende, ausgehende Mails werden gescannt und gegebenenfalls aussortiert.
Allerdings, die eigentliche Spam- und Virenabwehr sollte aber schon auf einem Firewallsystem beginnen! Nach Möglichkeit sollten zwei unterschiedliche Virenscannerhersteller vor dem Exchange den Mailfluss abarbeiten…
hmm ich habe vor 3-4 Wochen genau eine solche Konstellation installiert.
Server 2012, Exchange 2016 und Trend Micro worry free adv vers 9sp2
Läuft bisher alles ohne Probleme..
aber bisl Bauchweh hab ich nach dem post hier schon :)
Gemeint ist natürlich IIS
Hallo,
Genau dieses Problem hatte ich auch bei einem Kunden.Ich habe stundenlang nach einer Lösung gesucht und diese schliesslich gefunden.
Die Lösung ist es cgi des Webservers (ISS) zu deinstallieren und den Server dann neu zu starten.
Das Problem besteht nämlich darin das der Ordner unter Exchange Backend > Mapi > nspi defekt ist.