21
Zertifikatsfehler bei jedem outlook start
Hallo,
der Exchange 2013 mit aktuellem CU hat jetzt ein gekauftes Exchange SSL Zertifikat erhalten jedoch erhalten alle beim Outlook 2013-2019 starten eine rote proxy fehlermeldung danach noch
Sicherheitshinweis Ja/Nein/Zertifikat anzeigen. (auch bei den lokalen Domänen-PCs)
Frage: Was könnte hier das Problem sein?
Ziel: Fehlermeldung beim Outlook starten eliminieren.
Es gibt nicht soviele User, die sich ohne Domänen-PC mit Autodiscover bzw. Outlook Anywhere verbinden müssen (d.h. das Ziel ist nicht unbedingt, dass
non-domain-notebooks-mit-outlook sich vollautomatisch verbinden)
Im Chrome/IE wird das Zertifikat mit Schloss angezeigt (ohne rote "nicht sicher Schrift).
Wenn ein Domänenuser sich das das erste Mal an einem Domänen Notebook von ausserhalb im outlook anmeldet
funktioniert die Outlook-Profilerstellung indem der nur User/PW einträgt und im Wizard noch exchange 2013/älter auswählt.
Exchange ActiveSync
wird komplett grün angezeigt
https://testconnectivity.microsoft.com/tests/Eas/input
Outlook-Verbindung
Verbindungstest erfolgreich mit Warnungen
https://testconnectivity.microsoft.com/tests/Ola/input
der Exchange 2013 mit aktuellem CU hat jetzt ein gekauftes Exchange SSL Zertifikat erhalten jedoch erhalten alle beim Outlook 2013-2019 starten eine rote proxy fehlermeldung danach noch
Sicherheitshinweis Ja/Nein/Zertifikat anzeigen. (auch bei den lokalen Domänen-PCs)
Frage: Was könnte hier das Problem sein?
Ziel: Fehlermeldung beim Outlook starten eliminieren.
Es gibt nicht soviele User, die sich ohne Domänen-PC mit Autodiscover bzw. Outlook Anywhere verbinden müssen (d.h. das Ziel ist nicht unbedingt, dass
non-domain-notebooks-mit-outlook sich vollautomatisch verbinden)
Im Chrome/IE wird das Zertifikat mit Schloss angezeigt (ohne rote "nicht sicher Schrift).
Wenn ein Domänenuser sich das das erste Mal an einem Domänen Notebook von ausserhalb im outlook anmeldet
funktioniert die Outlook-Profilerstellung indem der nur User/PW einträgt und im Wizard noch exchange 2013/älter auswählt.
Exchange ActiveSync
wird komplett grün angezeigt
https://testconnectivity.microsoft.com/tests/Eas/input
Outlook-Verbindung
Verbindungstest erfolgreich mit Warnungen
https://testconnectivity.microsoft.com/tests/Ola/input
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1338298868
Url: https://administrator.de/forum/zertifikatsfehler-bei-jedem-outlook-start-1338298868.html
Ausgedruckt am: 14.04.2025 um 09:04 Uhr
21 Kommentare
Neuester Kommentar
Moin,
das Problem steht doch in der Meldung?!
Vergleiche mal die Zielwebsite in der einen Meldung und den Namen auf den das Zertifikat ausgestellt ist in der anderen.
/Thomas
Moin,
Auf welchen Namen ist das Zertifikat ausgestellt und wie lautet euer interner Mail-Server?
Entweder lauten beide Namen identisch oder ihr habt für interne Zwecke ein SAN-Zertifikat verwendet, bei dem beide Namen auftauchen.
Wie ist das autodiscover eingerichtet?
Gruß
em-pie
Auf welchen Namen ist das Zertifikat ausgestellt und wie lautet euer interner Mail-Server?
Entweder lauten beide Namen identisch oder ihr habt für interne Zwecke ein SAN-Zertifikat verwendet, bei dem beide Namen auftauchen.
Wie ist das autodiscover eingerichtet?
Gruß
em-pie
Hallo,
das bisherige selbst-erstellte-zertifikate ist unter ecp/server/zertifikate noch da (Diensten zugewiesen IMAP, POP, IIS, SMTP)
und läuft noch 2 Monate. Es beinhalet dies:
autodiscover.contoso.local
contoso.local
exchange.contoso.local (wird ja im Outlook Sicherheitshinwes bemängelt)
mail.contoso.de
autodiscover.contoso.de
Vergleiche mal die Zielwebsite in der einen Meldung und
den Namen auf den das Zertifikat ausgestellt ist in der anderen.
den Namen auf den das Zertifikat ausgestellt ist in der anderen.
@thomas
Das gekaufte Zerti hat zwei SANs und diesen Common Name: (hoffe richtig ausgedrückt)
common-name: mail.contoso.de
autodiscover.contoso.de
autodiscover.contoso-tocherfirma.de
@em-mpie
Auf welchen Namen ist das Zertifikat ausgestellt und wie lautet euer interner Mail-Server?
ausgestellt auf: mail.contoso.deinterner mailserver: exchange.contoso.local
Entweder lauten beide Namen identisch oder ihr habt für interne Zwecke
ein SAN-Zertifikat verwendet, bei dem beide Namen auftauchen.
ein SAN-Zertifikat verwendet, bei dem beide Namen auftauchen.
Wie ist das autodiscover eingerichtet?
Du meinst im Exchange ECP unter Server/vertuelle Verzeichnisse bzw. unter Zertifikate?
Soll ich davon ein Foto uploaden?
sorry hier im bild es ist nochmal besser sichtbar:
Idee: das bisherige selbst-erstellte-zertifikat ablaufdatum 2.1.2022 muss nur "inaktiv" geschaltet werden? (wie macht man das)
Zertifikat mit Datum 28.9.2022 ist das neue gekaufte Zertifikat.
Zertifikat mit Datum 28.9.2022 ist das neue gekaufte Zertifikat.
Zitat von @ManuManu2021:
@thomas
Das gekaufte Zerti hat zwei SANs und diesen Common Name: (hoffe richtig ausgedrückt)
common-name: mail.contoso.de
autodiscover.contoso.de
autodiscover.contoso-tocherfirma.de
@thomas
Das gekaufte Zerti hat zwei SANs und diesen Common Name: (hoffe richtig ausgedrückt)
common-name: mail.contoso.de
autodiscover.contoso.de
autodiscover.contoso-tocherfirma.de
Und wie heißt die URL die in der Fehlermeldung steht? Ist die auch im Zertifikat enthalten?
/Thomas
exchange.contoso.local
Da habt ihr wohl vergessen noch eine URL am Exchange anzupassen.Die URL für MAPIoHTTP wird oftmals vergessen wenn MAPIoHTTP aktiv ist und dann kommt zu oben genanntem Fehler (denn exchange.contoso.local ist ja nicht im Zertifikat enthalten) ...
https://docs.microsoft.com/de-de/powershell/module/exchange/set-mapivirt ...
https://www.windowspro.de/roland-eich/mapi-over-http-exchange-2013-2016- ...
Die anderen URLS müssen natürlich auch passen OAB/EWS usw.
Get-MapiVirtualDirectory | Set-MapiVirtualDirectory -InternalUrl "https://mail.contoso.de/mapi" -ExternalUrl "https://mail.contoso.de/mapi" -IISAuthenticationMethods Ntlm, OAuth, Negotiate Um welchen Dienst es sich handelt lässt sich leicht rausfinden indem man sich den Verbindungsstatus über das Outlook Tray-Icon anzeigen lässt (STRG-Rechtsklick) und mal einen Autodiscover Test durchlaufen lässt, da sieht man welche URL noch falsch ist.
Zitat von @Th0mKa:
Und wie heißt die URL die in der Fehlermeldung steht? Ist die auch im Zertifikat enthalten?
/Thomas
Zitat von @ManuManu2021:
@thomas
Das gekaufte Zerti hat zwei SANs und diesen Common Name: (hoffe richtig ausgedrückt)
common-name: mail.contoso.de
autodiscover.contoso.de
autodiscover.contoso-tocherfirma.de
@thomas
Das gekaufte Zerti hat zwei SANs und diesen Common Name: (hoffe richtig ausgedrückt)
common-name: mail.contoso.de
autodiscover.contoso.de
autodiscover.contoso-tocherfirma.de
Und wie heißt die URL die in der Fehlermeldung steht? Ist die auch im Zertifikat enthalten?
/Thomas
die url vom fehler sieht man im zuletzt geposteten screenshot von mir
Zitat von @149569:
Die URL für MAPIoHTTP wird oftmals vergessen wenn MAPIoHTTP aktiv ist und dann kommt zu oben genanntem Fehler (denn exchange.contoso.local ist ja nicht im Zertifikat enthalten) ...
https://docs.microsoft.com/de-de/powershell/module/exchange/set-mapivirt ...
https://www.windowspro.de/roland-eich/mapi-over-http-exchange-2013-2016- ...
Die anderen URLS müssen natürlich auch passen OAB/EWS usw.
Um welchen Dienst es sich handelt lässt sich leicht rausfinden indem man sich den Verbindungsstatus über das Outlook Tray-Icon anzeigen lässt (STRG-Rechtsklick) und mal einen Autodiscover Test durchlaufen lässt, da sieht man welche URL noch falsch ist.
exchange.contoso.local
Da habt ihr wohl vergessen noch eine URL am Exchange anzupassen.Die URL für MAPIoHTTP wird oftmals vergessen wenn MAPIoHTTP aktiv ist und dann kommt zu oben genanntem Fehler (denn exchange.contoso.local ist ja nicht im Zertifikat enthalten) ...
https://docs.microsoft.com/de-de/powershell/module/exchange/set-mapivirt ...
https://www.windowspro.de/roland-eich/mapi-over-http-exchange-2013-2016- ...
Die anderen URLS müssen natürlich auch passen OAB/EWS usw.
> Get-MapiVirtualDirectory | Set-MapiVirtualDirectory -InternalUrl "https://mail.contoso.de/mapi" -ExternalUrl "https://mail.contoso.de/mapi" -IISAuthenticationMethods Ntlm, OAuth, Negotiate
> Um welchen Dienst es sich handelt lässt sich leicht rausfinden indem man sich den Verbindungsstatus über das Outlook Tray-Icon anzeigen lässt (STRG-Rechtsklick) und mal einen Autodiscover Test durchlaufen lässt, da sieht man welche URL noch falsch ist.
danke das klingt vielversprechend,
die exchange 2013 (aktuelles cu) powershell antwortet dies (damit prüft mal wohl ob mapi da ist) und im
outlook unter verbindungsstatus ist scheinbar von rpc die Rede, siehe foto
[PS] C:\Windows\system32>Get-OrganizationConfig | fl name,mapi*
Name : contoso
MapiHttpEnabled : False
OK. Dann mach mal ein Autodiscover-Test (ebenfalls über STRG-Rechtsklick > "E-Mail Autokonfiguration testen"), dort sollten alle URLs auftauchen die Exchange an den Client übermittelt. Daran sollte man erkennen können für welchen Dienst noch eine andere URL benutzt wird. OAB/EWS usw ...
Die URL beginnt mit Exchange, das sieht man schon im ersten Bild. Entweder ist also die URL falsch oder das Zertifikat.
Ich weiß "nur", dass EWS z.B. für Warenwirtschaft nicht verwendet, anders gesagt, bzw. OAB/EWS wurde nie was geändert/gemacht soweit ich weiß.
Also hier wurde schon mal der Service-Connection-Point nicht angepasst
Ich weiß "nur", dass EWS z.B. für Warenwirtschaft nicht verwendet, anders gesagt, bzw. OAB/EWS wurde nie was geändert/gemacht soweit ich weiß.
EWS wird immer benötigt! Selbst OWA und viele andere Dienste benötigen das zwingend!
Moin...
da wird nix "inaktiv" geschaltet... das neue wird aktiviert und die dienste zugewiesen werden...
das alte dann gelöscht!
wenn das wirklich so ist, hast du einen fehler gemacht, es fehlt exchange.contoso.de!
nutze für intern und extern am besten die gleichen urls... bzw. san namen...
Frank
Zitat von @ManuManu2021:
Idee: das bisherige selbst-erstellte-zertifikat ablaufdatum 2.1.2022 muss nur "inaktiv" geschaltet werden? (wie macht man das)
Zertifikat mit Datum 28.9.2022 ist das neue gekaufte Zertifikat.
Idee: das bisherige selbst-erstellte-zertifikat ablaufdatum 2.1.2022 muss nur "inaktiv" geschaltet werden? (wie macht man das)
Zertifikat mit Datum 28.9.2022 ist das neue gekaufte Zertifikat.
da wird nix "inaktiv" geschaltet... das neue wird aktiviert und die dienste zugewiesen werden...
das alte dann gelöscht!
Das gekaufte Zerti hat zwei SANs und diesen Common Name: (hoffe richtig ausgedrückt)
common-name: mail.contoso.de
autodiscover.contoso.de
autodiscover.contoso-tocherfirma.de
common-name: mail.contoso.de
autodiscover.contoso.de
autodiscover.contoso-tocherfirma.de
wenn das wirklich so ist, hast du einen fehler gemacht, es fehlt exchange.contoso.de!
nutze für intern und extern am besten die gleichen urls... bzw. san namen...
Frank
Zitat von @Vision2015:
Moin...
da wird nix "inaktiv" geschaltet... das neue wird aktiviert und die dienste zugewiesen werden...
das alte dann gelöscht!
wenn das wirklich so ist, hast du einen fehler gemacht, es fehlt exchange.contoso.de!
nutze für intern und extern am besten die gleichen urls... bzw. san namen...
Frank
Moin...
Zitat von @ManuManu2021:
Idee: das bisherige selbst-erstellte-zertifikat ablaufdatum 2.1.2022 muss nur "inaktiv" geschaltet werden? (wie macht man das)
Zertifikat mit Datum 28.9.2022 ist das neue gekaufte Zertifikat.
Idee: das bisherige selbst-erstellte-zertifikat ablaufdatum 2.1.2022 muss nur "inaktiv" geschaltet werden? (wie macht man das)
Zertifikat mit Datum 28.9.2022 ist das neue gekaufte Zertifikat.
da wird nix "inaktiv" geschaltet... das neue wird aktiviert und die dienste zugewiesen werden...
das alte dann gelöscht!
Das gekaufte Zerti hat zwei SANs und diesen Common Name: (hoffe richtig ausgedrückt)
common-name: mail.contoso.de
autodiscover.contoso.de
autodiscover.contoso-tocherfirma.de
common-name: mail.contoso.de
autodiscover.contoso.de
autodiscover.contoso-tocherfirma.de
wenn das wirklich so ist, hast du einen fehler gemacht, es fehlt exchange.contoso.de!
nutze für intern und extern am besten die gleichen urls... bzw. san namen...
Frank
Hi Frank,
danke für dein Kommentar.
Es ist ja folgendes Certum Zerti, da kann man SANs nachkaufen soweit ich weiß.
Certum Commercial SSL SAN
(ob man nochmal dafür neuen CSR generieren muss und dann was am lokalen exchange machen muss weiß ich spontan nicht) https://www.psw-group.de/ssl-zertifikate/certum-commercial-san-a001007/
Dein vorgeschlagener Weg vierter SAN exchange.contoso.de nachzukaufen: ich habe wenig Erfahrung mit gekauften Exchangezertifikaten, aber bei den vereinzelten gekauften Zertis war es bisher
nicht notwendig das <"lokaler-dns-exchange-servername">.contoso.de mit als SAN auf dem Zerti sein musste.
Anders gesagt: Der lokale Exchange ist aktuell halt so konfiguriert das die Outlooks beim starten auch nach exchange.contoso.de suchen und am einfachsten wäre es diesen vierten SAN exchange.contoso.de für 19€ SAN nachzukaufen?
nutze für intern und extern am besten die gleichen urls... bzw. san namen...
Ich dachte bisher das Outlook nur autodiscover.contoso.de bzw. autodiscover.contoso.local beim starten sucht/braucht.
Das ist doch alles vieeeel zu kompliziert.
Wir haben damals ein Wildcard-Zertifikat gekauft. Das ist in unserer UTM hochgeladen worden.
Da die UTM auch einen ReverseProxy für die Außenwelt bereitstellt, ist der Exchange von außen nur bis zur UTM offiziell validiert.
Intern haben wir dem Exchange ein SAN über unsere eigene CA gesponsert. Zusätzlich zeigt ein Alias „Exchange.Company.tld“ im internen DNS auf den Mailserver.contoso.Local (ja, Local ist doof, aber mal eben alles umstellen, was vor ~25 Jahren etabliert wurde, ist nicht).
Intern läuft somit alles über das vom eigenen CA verifiziertet Zertifikat und extern über das gekaufte.
Ansonsten kaufst du nur EIN SAN und gut
Wir haben damals ein Wildcard-Zertifikat gekauft. Das ist in unserer UTM hochgeladen worden.
Da die UTM auch einen ReverseProxy für die Außenwelt bereitstellt, ist der Exchange von außen nur bis zur UTM offiziell validiert.
Intern haben wir dem Exchange ein SAN über unsere eigene CA gesponsert. Zusätzlich zeigt ein Alias „Exchange.Company.tld“ im internen DNS auf den Mailserver.contoso.Local (ja, Local ist doof, aber mal eben alles umstellen, was vor ~25 Jahren etabliert wurde, ist nicht).
Intern läuft somit alles über das vom eigenen CA verifiziertet Zertifikat und extern über das gekaufte.
Ansonsten kaufst du nur EIN SAN und gut
Zitat von @ManuManu2021:
Hi Frank,
danke für dein Kommentar.
Es ist ja folgendes Certum Zerti, da kann man SANs nachkaufen soweit ich weiß.
Certum Commercial SSL SAN
(ob man nochmal dafür neuen CSR generieren muss und dann was am lokalen exchange machen muss weiß ich spontan nicht) https://www.psw-group.de/ssl-zertifikate/certum-commercial-san-a001007/
ja.. natürlich brauchst du ein neuen CSR!Zitat von @Vision2015:
Moin...
da wird nix "inaktiv" geschaltet... das neue wird aktiviert und die dienste zugewiesen werden...
das alte dann gelöscht!
wenn das wirklich so ist, hast du einen fehler gemacht, es fehlt exchange.contoso.de!
nutze für intern und extern am besten die gleichen urls... bzw. san namen...
Frank
Moin...
Zitat von @ManuManu2021:
Idee: das bisherige selbst-erstellte-zertifikat ablaufdatum 2.1.2022 muss nur "inaktiv" geschaltet werden? (wie macht man das)
Zertifikat mit Datum 28.9.2022 ist das neue gekaufte Zertifikat.
Idee: das bisherige selbst-erstellte-zertifikat ablaufdatum 2.1.2022 muss nur "inaktiv" geschaltet werden? (wie macht man das)
Zertifikat mit Datum 28.9.2022 ist das neue gekaufte Zertifikat.
da wird nix "inaktiv" geschaltet... das neue wird aktiviert und die dienste zugewiesen werden...
das alte dann gelöscht!
Das gekaufte Zerti hat zwei SANs und diesen Common Name: (hoffe richtig ausgedrückt)
common-name: mail.contoso.de
autodiscover.contoso.de
autodiscover.contoso-tocherfirma.de
common-name: mail.contoso.de
autodiscover.contoso.de
autodiscover.contoso-tocherfirma.de
wenn das wirklich so ist, hast du einen fehler gemacht, es fehlt exchange.contoso.de!
nutze für intern und extern am besten die gleichen urls... bzw. san namen...
Frank
Hi Frank,
danke für dein Kommentar.
Es ist ja folgendes Certum Zerti, da kann man SANs nachkaufen soweit ich weiß.
Certum Commercial SSL SAN
(ob man nochmal dafür neuen CSR generieren muss und dann was am lokalen exchange machen muss weiß ich spontan nicht) https://www.psw-group.de/ssl-zertifikate/certum-commercial-san-a001007/
Dein vorgeschlagener Weg vierter SAN exchange.contoso.de nachzukaufen: ich habe wenig Erfahrung mit gekauften Exchangezertifikaten, aber bei den vereinzelten gekauften Zertis war es bisher
nicht notwendig das <"lokaler-dns-exchange-servername">.contoso.de mit als SAN auf dem Zerti sein musste.
Anders gesagt: Der lokale Exchange ist aktuell halt so konfiguriert das die Outlooks beim starten auch nach exchange.contoso.de suchen und am einfachsten wäre es diesen vierten SAN exchange.contoso.de für 19€ SAN nachzukaufen?
nutze für intern und extern am besten die gleichen urls... bzw. san namen...
Ich dachte bisher das Outlook nur autodiscover.contoso.de bzw. autodiscover.contoso.local beim starten sucht/braucht.
AutoErmittlungsdienst in Exchange Server
Exchange 2016: Die Basiskonfiguration
Frank
Die Proxy-Fehlermeldung kenne ich so auch nicht.
Die andere kann ich Dir so deuten:
Der Server wird mit einem anderen DNS-Namen angesprochen, als im Zertifikat hinterlegt.
Das ist bei uns so gelöst, dass der Name im Zertifikat unser offizieller ist und intern über die nicht öffentliche IP aufgelöst wird.
Gruß
bdmvg
Die andere kann ich Dir so deuten:
Der Server wird mit einem anderen DNS-Namen angesprochen, als im Zertifikat hinterlegt.
Das ist bei uns so gelöst, dass der Name im Zertifikat unser offizieller ist und intern über die nicht öffentliche IP aufgelöst wird.
Gruß
bdmvg
Zitat von @149569:
Also hier wurde schon mal der Service-Connection-Point nicht angepasst
Also hier wurde schon mal der Service-Connection-Point nicht angepasst
Danke!
autodiscover Service Connection Point / Exchange SCP
anpassen klingt nachfolgend auch gut
Zitat/auszug von folgender quelle:
https://deer-it.de/autodiscover-service-connection-point-exchange-scp/
es steht dort so:
rausfinden welcher SCP vorhanden ist:
Get-ClientAccessServer -Identity Server | fl
bei Punkt “AutoDiscoverServiceInternalUri”.
ändern:
Set-ClientAccessServer -Identity Server -AutoDiscoverServiceInternalUri https://autodiscover.contoso.de/Autodiscover/Autodiscover.xm
Wird der Eintrag angepasst, muss sichergestellt sein, dass der FQDN auf dem Zertifikat, welches auf dem Exchange Server hinterlegt ist, enthalten ist. Sonst bekommen die Outlook Clients beim starten eine Zertifikatswarnung.
Das heißt wenn der Eintrag zum Beispiel auf “https://autodiscover.contooso.de/Autodiscover/Autodiscover.xml” abgeändert wird, MUSS auf der Eintrag “autodiscover.autodiscover.de” auf dem Zertifikat vorhanden sein.
Nachdem der AutodiscoverServiceInternalUri angepasst wurde muss der IIS neugestartet werden und die Domänen Controller müssen repliziert werden.
Zitat ende
Zitat von @em-pie:
Das ist doch alles vieeeel zu kompliziert.
Wir haben damals ein Wildcard-Zertifikat gekauft. Das ist in unserer UTM hochgeladen worden.
Da die UTM auch einen ReverseProxy für die Außenwelt bereitstellt, ist der Exchange von außen nur bis zur UTM offiziell validiert.
Intern haben wir dem Exchange ein SAN über unsere eigene CA gesponsert. Zusätzlich zeigt ein Alias „Exchange.Company.tld“ im internen DNS auf den Mailserver.contoso.Local (ja, Local ist doof, aber mal eben alles umstellen, was vor ~25 Jahren etabliert wurde, ist nicht).
Intern läuft somit alles über das vom eigenen CA verifiziertet Zertifikat und extern über das gekaufte.
Ansonsten kaufst du nur EIN SAN und gut
Das ist doch alles vieeeel zu kompliziert.
Wir haben damals ein Wildcard-Zertifikat gekauft. Das ist in unserer UTM hochgeladen worden.
Da die UTM auch einen ReverseProxy für die Außenwelt bereitstellt, ist der Exchange von außen nur bis zur UTM offiziell validiert.
Intern haben wir dem Exchange ein SAN über unsere eigene CA gesponsert. Zusätzlich zeigt ein Alias „Exchange.Company.tld“ im internen DNS auf den Mailserver.contoso.Local (ja, Local ist doof, aber mal eben alles umstellen, was vor ~25 Jahren etabliert wurde, ist nicht).
Intern läuft somit alles über das vom eigenen CA verifiziertet Zertifikat und extern über das gekaufte.
Ansonsten kaufst du nur EIN SAN und gut
danke ja stimmt, gar nicht lange fackeln.
WAF/Reverse Proxy ist aktuell noch nicht vorhanden, es ist watchguard .
Habe dieses BOC Tutorial noch nicht gelesen, scheinbar muss man "vorher MAPI over HTTP" aktivieren
https://www.boc.de/watchguard-info-portal/2020/02/kompatibilitaet-https- ...
