none
Versand von Bildern mit Android Smartphone RRS feed

  • Frage

  • Hallo,

    wir betreiben einem Exchange 2016 CU19 bei dem ein Problem beim Versand von Bildern mit Android Smartphones auftritt.

    Mitarbeiter machen bei Kunden vor Ort Fotos mit Ihrem Smartphones und verschicken diese per Email, wobei die integrierte GMail-App der Samsung Smartphones zum Einsatz kommt.

    Das Problem tritt auf, egal ob die Bilder aus der App heraus zur Email hinzugefügt werden, oder ob die "Teilen"-Funktion des Datei-Managers verwendet wird.

    Auf dem Smartphone bleibt die Email im Postausgang mit der Meldung "In der Warteschlange" liegen, bis es irgendwann zu einer Zeitüberschreitung kommt.

    Auf dem Exchange habe ich als relevante Meldung lediglich einen Eintrag im IIS-Log gefunden:

    POST /Microsoft-Server-ActiveSync/Proxy/default.eas Cmd=Ping&User=<Domäne\Username>&DeviceId=androidc221184382&DeviceType=Android&Log=Error:NMStolen_SC1:1_PrxFrom:fe80%3a%3ad012%3a59%3a82b8%3ab6b0%252_Ver1:160_HH:<FQDN des Exchange>_SmtpAdrs:<Sender-Email>_FldrC1:7_Fid:12_PSyncType1:N_Fid:23_PSyncType1:N_Fid:25_PSyncType1:N_Fid:29_PSyncType1:N_Fid:30_PSyncType1:N_Fid:61_PSyncType1:N_Fid:74_PSyncType1:N_Hb:1380_Hang:0_Fet:213_Mbx:<interner Exchange-Name>_Cafe:<interner Exchange-Name>_Throttle:0_SBkOffD:BBkOff%3aL%2f-470%2c+ABBkOff%3aL%2f-480%2c+EffBkOff%3aL%2f-470_CmdHash1:-1483793340_SyncHash1:1044245961_TmRcv:13:01:57.0977062_TmSt:13:01:57.0987424_TmDASt:13:01:57.1067548_TmPolSt:13:01:57.1067548_TmExSt:13:01:57.1077416_TmExFin:13:01:57.1627426_TmFin:13:01:57.1627426_TmCmpl:13:01:57.3088326_TmHang:13:01:57.1617436_IcsHier:T_OMSt:3_Budget:(A)Owner%3aS-1-5-21-3218577135-367456171-2094260488-1125%5Fandroidc221184382%5FAndroid%2cConn%3a0%2cMaxConn%3a10%2cMaxBurst%3a480000%2cBalance%3a480000%2cCutoff%3a600000%2cRechargeRate%3a1800000%2cPolicy%3aCustom-RCAMaxConcurrency%2cIsServiceAccount%3aFalse%2cLiveTime%3a00%3a00%3a20.5170306%3b(D)Owner%3aS-1-5-21-3218577135-367456171-2094260488-1125%5Fandroidc221184382%5FAndroid%2cConn%3a0%2cMaxConn%3a10%2cMaxBurst%3a480000%2cBalance%3a480000%2cCutoff%3a600000%2cRechargeRate%3a1800000%2cPolicy%3aCustom-RCAMaxConcurrency%2cIsServiceAccount%3aFalse%2cLiveTime%3a00%3a00%3a20.7271208_ActivityContextData:ActivityID%3dc803f6ab-2ff2-41f0-8249-1fad19a81afd%3bS%3aWLM.BT%3dEas%3bS%3aWLM.Bal%3d480000_ 444 <Domäne\Username> fe80::d012:59:82b8:b6b0%2 Android-Mail/2020.11.29.346182102.Release - 200 0 0 214

    Zu dem Fehler "Error:NMStolen_SC1:1" habe ich bisher lediglich Aussagen gefunden, dass der Wert für den Parameter "uploadReadAheadSize" zu klein sei (angeblich kann diese Meldung ausgeworfen werden, wenn der Wert kleiner als die Größe der Anhänge ist.

    Die Modifikation des Werts hat aber das Problem leider nicht gelöst.

    Der Fehler tritt nur bei Bildern auf, andere Anhänge sind davon nicht betroffen.

    Ich könnte mir vorstellen, dass dieser Effekt darin begründet liegt, dass Bilder standardmäßig inline gesendet werden, während andere Dateitypen als Anhänge mit der Mail transportiert werden, aber wie kann ich das ändern ?

    Grüße

    Tobias

    Montag, 11. Januar 2021 13:16

Antworten

  • Wir haben folgende Einstellungen dafür anpassen müssen fürs FE und BE Virtual Directory .
    maxRequestLength
    MaxDocumentDataSize
    uploadReadAheadSize

    Grüße
    Jörg

    Dienstag, 12. Januar 2021 16:37

Alle Antworten

  • Das ist eine Einschränkung im IIS für das Hochladen:
    https://docs.microsoft.com/en-us/iis/configuration/system.webserver/serverruntime

    Das sollte auch für neuere Versionen gelten.

    Handybilder können inzwischen auch schon mal ein paar mehr MB's werden.

    Montag, 11. Januar 2021 13:42
  • Wir haben folgende Einstellungen dafür anpassen müssen fürs FE und BE Virtual Directory .
    maxRequestLength
    MaxDocumentDataSize
    uploadReadAheadSize

    Grüße
    Jörg

    Dienstag, 12. Januar 2021 16:37
  • Hallo Suchender,

    meinst Du, dass die Mails evtl. einfach das Default-Limit überschreiten `?

    Ich habe den Wert "maxAllowedContentLength" im Komnfigurationseditor für Fron- und Backend unter system.webServer.security auf 89254789 gesetzt, was für ungefähr 64MB (Netto) gut sein sollte.Die fraglichen Mails hatten Anhänge mit einer Gesamtgröße von ca. 10MB.

    Welche Werte könnten sonst noch relevant sein ?

    Grüße

    Tobias

    Dienstag, 12. Januar 2021 17:33
  • Hallo Jörg,aufgrund der Schlüsselwörter maxRequestLength und maxDoxcumentDataSize bin ich auf https://www.frankysweb.de/exchange-2016-groessenbeschraenkung-fuer-activesync-veraendern/ gestoßen.

    Auf welchen Wert hast Du uploadReadAheadSize gesetzt ? So hoch wie die erlaubte Maximalgröße der Email ?

    Grüße

    Tobias

    Dienstag, 12. Januar 2021 17:44
  • Hi Tobias,
    genau so, auf die Maximalgröße der Mails
    Mittwoch, 13. Januar 2021 11:36
  • Hat funktioniert.

    Danke.

    Donnerstag, 14. Januar 2021 08:53