Beiträge von mw42

    Hallo zusammen,


    auf einem Android Gerät möchte ich gern die Mail-Software "Nine" (Hersteller 9Folders) nutzen. Der Mailserver hat für seine Adresse ein Let's Encryt Zertifikat. Doch ich bekomme ausserhalb des Firmennetzes keine Verbindung zum Server offenbar auf Grund eines Zertifikatproblems. Im Logfile von Nine erscheint die Zeile:

    Code
    javax.net.ssl.SSLPeerUnverifiedException: No peer certificate

    Ich verstehe das so dass hier offenbar nur das Zertifikat selbst, nicht aber die Zertifikatskette ausgegeben wird (also Let's Encrypt X3 sowie deren übergeordnete Stelle).


    Wie kann ich das im Exchange bzw. im IIS des Exchange-Server korrigieren?


    Ach so, mit "Outlook für Android" tritt dieses Verhalten nicht auf, jedoch möchte ich Outlook ungern weiter nutzen, deshalb suche ich nach einer Lösung meines Problems.


    Danke

    Hallo Community,


    bei genau einem Mitarbeiter schlägt der Abruf von Mail / Kalender / öffentlichen Kalendern immer mal wieder fehl, jedoch nur wenn er im WLAN bei sich zuhause eingeloggt ist.


    Zuerst aufgefallen ist dies vor einigen Wochen, er bekam auf iPhone / iPad zuhause Zugriffsfehlermeldungen und keine neuen Mails / Einträge. Nachdem wir dort keine Ursache finden konnten hatte sich das erstaunlicherweise nach einigen Tagen von selbst gelöst und die Fehler traten nicht mehr auf.


    Nun habe ich am Freitag die Windows Server 2016 / Exchange 2016 Updates der letzten Woche installiert, Montag früh kam dann die Rückmeldung "Geht seit Freitag schon wieder nicht".


    Ich habe also EINEN Mitarbeiter, bei dem MANCHMAL nur in seinem WLAN der Zugriff nicht klappt. Bei einem weiteren Mitarbeiter ist dieses Problem nie aufgetreten (oder er hat es nicht gemeldet).
    Irgendeine Idee an welcher Stelle ich hier nach Ursachen suchen kann? Bestimmte Protokolle im Exchange?


    Danke

    Da es mit der Integration von den Ordnern über die geteilte Mailbox läuft war das alles nicht mehr so kritisch.


    Aber ich möchte den 2010er halt doch zeitnah ausmustern.


    Ich habe jedoch wirklich KEINE neuen Erkenntnisse zu meiner blöden Fehlerthematik finden können. Offenbar gibt es einfach niemand, der dieses Problem hatte UND auch gelöst bekam.


    Ich WÜRDE eine normale Migration vorziehen, aber wenn meine beschriebene Vorgehensweise so klappen kann dann mach ich das einfach an einem ruhigen Wochenende und bin dann durch mit dem Mist :(

    Hi,


    nachdem meine Migration meiner öffentlichen Ordner von Ex2010 auf Ex2016 nicht geklappt hat möchte ich diese nun manuell verschieben. Aktuell sind alle Mailboxen auf 2016 migriert und die Öffentlichen Ordner noch immer auf 2010, eingebunden per shared mailbox auf dem Ex2016. Somit kann jeder Benutzer mit Outlook auf beides zugreifen.


    Ist folgendes Szenario möglich oder ist davon abzuraten:

    • Öffentlichen Ordner auf Ex2016 anlegen, als Beispiel den (auf Ex2010 bereits existenten) Ordner "EDV"
    • Mail-enabled für Ordner "EDV" auf Ex2010 abschalten
    • Mail-enabled für Ordner "EDV" auf Ex2016 einschalten
    • Als (ausreichend berechtigter) Nutzer in Outlook auf den alten "EDV" zugreifen und per "verschieben nach..." in den neuen "EDV" Ordner verschieben (also vom alten auf den neuen Server)
    • Prozedur für alle vorhandenen Ordner auf Ex2010 wiederholen

    Danke
    Martin

    So, mal ein Update zu dieser Thematik:


    Aktuell kann ich Outlook wieder nutzen, allerdings für alle Benutzer nur mit "Set-CASMailbox <user> -MapiHttpEnabled $false".


    Das Problem scheint an unserer Firewall zu liegen (Sophos UTM). Bei dieser wird Exchange 2016 offiziell gar nicht unterstützt :cursing: Muss man drauf kommen. Es gibt einen Artikel als Workaround von Sophos dafür; nach EInrichtung ging dann der Zugriff von aussen nicht mehr, aber das ist grad erstmal egal. Sophos Support ist informiert und wird sich bald kümmern.


    Bis zu dem Zeitpunkt (Outlook ging intern nicht, FIrewall noch nicht umgestellt) ging es von aussen nämlich sehr gut. Autoconfig und sowas hat alles prima geklappt, und das hat mich dann auf den Fehler in der internen Kommunikation gebracht.


    Ich berichte später nochmal...

    Mal davon abgesehen dass es sicher keine Dauerlösung sein sollte, Mapi zu deaktivieren, so hilft es doch momentan extrem weiter da die Mitarbeiter wieder Outlook nutzen können.

    Es ist mir durchaus bewusst dass

    • es keine SINNVOLLE Lösung ist
    • es besser wäre die Ursache des Problems mit MAPI zu finden

    Momentan muss ich zusehen dass die Mitarbeiter erstmal wieder ihr Outlook nutzen können. Wenn das bedeutet dass ich für einen kurzen Zeitraum auf Mapi verzichten muss dann nehme ich das gern in Kauf. Vor allem verschafft mir das etwas Zeit um weiter an der Mapi Problematik zu arbeiten.


    Externe Hilfe habe ich kontaktiert.


    Es hätte ja möglich sein können dass hier im Forum jemand einen effektiven Rat zur der "Mapi lässt sich nicht abschalten" Thematik weiss. Das - wie gesagt - hälfe mir im Moment weiter.

    So, es gibt Neuigkeiten:


    Hatte heute morgen die Idee testweise mal für einen Nutzer (mich selbst) "MapiOverHttp" zu deaktivieren per

    Code
    Set-CASMailbox user -MapiHttpEnabled $false


    Dies führte dazu dass ich mich mit diesem Benutzer sofort wieder bei Outlook (2016) ohne Passwort-Abfrage einloggen konnte. Auch meine öffentlichen Ordner (welche noch auf dem Exchange 2010 liegen) sind nutzbar. Soweit so gut, ABER:


    Bisher habe ich bei 10 weiteren Nutzern diese Umstellung versucht und nur bei einem einzigen hat das dann auch geklappt. Bei allen anderen kommt entweder weiterhin die Nutzername / Passwort Abfrage und dann kann Outlook nicht mal mehr gestartet werden oder - falls Outlook nach Abbrechen der Passwortabfrage sich noch öffnet - ich kann dann in den Verbindungseinstellungen (STRG + Klick auf das Outlooksymbol in der Taskleiste) sehen dass als Protokoll "HTTP" benutzt wird und die Auth* fehlschlägt.


    Weiterhin versucht habe ich:

    Code
    Set-OrganizationConfig -MapiHttpEnable $false
    
    
    Set-CASMailbox [alle anderen User] -MapiHttpEnable $false

    Zudem habe ich auf den Client Rechnern in der Registry den Eintrag gesetzt "DWORD: MapiHttpDisabled" = 1 unter HKLU\Software\Microsoft\Exchange


    Was mir aufgefallen ist:
    Im EAC unter Postfächer waren die Einstellungen "Mapi" immer noch auf "enabled" gesetzt. Habe das auch dort umgestellt, auch keine Auswirkung.



    Ach so: Der auch funktionierende Nutzer ist KEIN Admin, mein Konto schon; diese Nutzer und alle anderen auch sind bereits mit der Mailbox auf 2016 migriert. Jeder Nuzter hat eigenen PC. Alle nutzen Windows 10 + Outlook 2016.




    Mal davon abgesehen dass es sicher keine Dauerlösung sein sollte, Mapi zu deaktivieren, so hilft es doch momentan extrem weiter da die Mitarbeiter wieder Outlook nutzen können.
    Worauf muss ich noch achten damit ich für einen Nutzer Mapi effektiv deaktivieren kann ?