Warnung: Trend Micro Worry Free 9 und Exchange 2016

Eine nette Leserin fragte mich, ob ich eine Möglichkeit kenne, das MAPIoverHTTP Protokoll für Exchange 2016 zurückzusetzen bzw. neu zu installieren. Es gibt zwar Möglichkeiten MAIPoverHTTP zu reseten, jedoch ist fraglich ob das in diesem Fall geholfen hätte. Hier also eine kleine Geschichte zum Thema Kompatibilität von Trend Micro Worry Free(!?) 9 und Exchange 2016. Silke hat mich freundlicherweise erlaubt die Informationen hier zu veröffentlichen, damit nicht mehr Admins in diesen Problem laufen. Danke Silke!

Hier also die Mail von Silke:

Kurzversion

Bei der  Installation des Messaging Server Agents aus der Trend Micro Worry Free Business Security 9.0 SP2 auf einem Windows Server 2012 R2 mit Exchange 2016 wird MAPI irreparabel zerstört.

Langversion

Ich schlage demnächst an der 75er Grenze meines SBS 2011 Premium (Server 2008 R2 mit Exchange 2010 und dezidiertem SQL-Server) an, und abgesehen davon muss das Teil jetzt auch endlich mal raus. Also ziehe ich das gesamte System auf mehrere Server 2012 R2 und die entsprechenden aktuellen Versionen von Exchange und SQL um. Server und SQL sind fertig, jetzt ist gerade Exchange dran.

Ich habe also Windows Server 2012 R2 auf einer neuen Maschine installiert, in die Domain eingebunden und auf dem blütenweißen Server Exchange 2016 installiert. Dann habe ich das Teil komplett konfiguriert, getestet und die User umgezogen. Alles gut, Zugriff über Outlook, OWA und ECP problemlos.

Bevor ich den Empfang auf den neuen Server umhänge, sollte da noch ein Virenscanner drauf… dachte ich mir <räusper>. Im System läuft Trend Micro Worry Free Business Security (TM WFBS) 9.0 (aktuelles Patchlevel).. WFBS hat außer den Security Agents für die Desktops und Server auch einen Messaging Security Agent für Exchange Server. Der wird installiert, indem der neue Exchange der Verwaltungskonsole der WFBS hinzugefügt wird.

Sofort nach der Installation konnten sich meine Outlook-Clients (2010 und 2016) nicht mehr verbinden. Ein neues Profil scheiterte daran, dass der Exchange angeblich nicht mehr erreichbar war,  OWA und ECP funktionierten weiter problemlos. Also habe ich erst mal alle betroffenen User mit OWA vertraut gemacht und dann Trend Micro und MS kontaktiert.

Hier mal die relevanten Antworten:

Antwort 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!

Antwort 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.

Ende

An dieser Stelle wurde dann auch nicht mehr versucht, MAPIoverHTTP wieder zum Leben zu erwecken. Wer weiß schon, was für faule Eier man sich noch ins Nest gelegt hat. Die Neuinstallation ist hier wahrscheinlich der einfachere Weg. Auf der Trend Micro Website habe ich keine Informationen gefunden, das Worry Free (netter Name in diesem Zusammenhang) schon kompatibel mit Exchange 2016 ist. Im Handbuch der Systemvoraussetzungen wird nur Exchange 2013 genannt, aber das scheint auch schon länger nicht mehr gepflegt zu werden, denn das SP für Exchange 2013 wird noch mit N/A angegeben:

Worry Free

Gerade Virenscanner verursachen immer wieder Probleme auf Exchange Servern, hier muss also die Kompatibilität unbedingt vorher sichergestellt werden. Auch die entsprechenden Ausschlüsse müssen konfiguriert werden:

https://technet.microsoft.com/en-us/library/bb332342(v=exchg.160).aspx

Falls Ihr auch solche Geschichten kennt, könnt ihr sie mir gerne zusenden. Ich finde es immer hilfreich von solchen Problemen im Vorfeld gehört zu haben :-)

Vielen Dank an dieser Stelle noch einmal an Silke, die der Veröffentlichung zugestimmt hat.

Ich gehe sogar soweit zu behaupten, dass auf Exchange Servern kein Virenscanner installiert werden muss, sondern ein etwas anderes Konzept zu mehr Erfolg und weniger Problemen führt:

Exchange

Wie seht ihr das? Meinungen dazu gerne in die Kommentare schreiben.

17 Kommentare zu “Warnung: Trend Micro Worry Free 9 und Exchange 2016”

  1. 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.

  2. 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 :)

  3. 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…

  4. 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?

  5. 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?

  6. 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.

  7. 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..

  8. 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.

  9. 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

  10. 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.

  11. 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.

  12. 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

  13. 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

    1. 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

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.