Das Ganze kann man über den/die Exchange-Server regeln, dass dies nachher funktioniert.

Als erstes sollte man aber kontrollieren ob die allgemeinen Exchange-Limits richtig gesetzt sind, z.B. auf 50MB.  Mit der Exchange Shell geht dies sehr einfach:

• get-TransportConfig | fl maxSendSize
• get-SendConnector | fl name, maxMessageSize
• get-ReceiveConnector | fl name, maxMessageSize
• get-Mailbox name | fl maxSendSize

Wenn hier überall 50MB (oder der gewünschte Wert) angezeigt wird, scheint theoretisch alles okay zu sein.
–> Wenn ein Wert nicht stimmen sollte kann das bequem mit der Management Konsole geändert werden! Siehe entsprechender Tab (also Hub Transport, Sende Konnektor, etc.) Dies funktioniert per Eingabe&Klick, also nichts, was man falsch machen kann.

Jedoch ist dem bezüglich MAC Zugriff (Webservices) nicht so. Die genannten Einstellungen oben müssen zwar korrekt sein, aber für den Mac muss es eingehender konfiguriert werden.

Dazu muss EWS anderst konfiguriert werden:

• In der Datei C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\exchweb\ews\web.config muss der Wert von “maxReceivedMessageSize” unter <EWSMessageEncoderSoap11Element /> geändert werden:
  • Zum Beispiel auf 50MB: 
    <EWSMessageEncoderSoap11Element />
    <httpsTransport maxReceivedMessageSize=”52428800″ …>
  • Hinweis: Diese Angabe ist in Bytes.
    
• Da wir gleich in dieser Datei sind, ändern wir auch den Wert vom WebAccess (OWA) auf 50MB, der ist nämlich standardmässig auf 30MB.
  • <httpRuntime maxRequestLength=”51200″ />
  • Hinweis: Wichtig: Diese Angabe ist in Kilobytes. Ist sie zu hoch (z.B. wenn man die Umrechnung von Bytes auf KB vergisst…), funktioniert der EWS-Zugriff (Mac, Blackberry, etc.) nicht mehr.
• Mit der Eingabeaufforderung und C:\Windows\System32\inetsrv\appcmd.exe muss noch der Wert von maxAllowedContentLength angepasst werden.
  • Setzen wir das wieder auf 50MB:
    appcmd set config “Default Web Site/ews” -section:requestFiltering /requestLimits.maxAllowedContentLength:52428800
  • Hinweis: Das sind nun wieder Bytes.
• Um die Änderungen zu übernehmen muss der IIS Dienst (WWW Web Publishing) neu gestartet werden (iisreset). 

Ich hatte heute unser Hosted Exchange Service (www.hex2007.ch) auf den neusten Stand gebracht. Auf Exchange 2007 SP2 inkl. Rollup 1.
Dadurch sind wir nun mit Exchange 2010 kompatibel, bzw. können dann einfach upgraden, sobald wir das für nötig oder vorteilhaft empfinden.

Eine solche weitläufige Update Installation ist aber nicht ganz simpel und muss auch überlegt sein.
Ebenfalls nimmt sie sehr viel Zeit in Anspruch. Die grösste Herausforderung ist natürlich, dass immer alles verfügbar bleibt.

Hier das Vorgehen für SOLL-Status Exchange 2007 SP2 & Rollup 1 auf Basis von IST SP1 mit Rollup 9.

• Installieren aller noch offenen Windows Updates auf sämtlichen Frontends und Cluster Nodes
• Dies jeweils Zeitverschoben um die Verfügbarkeit zu haben, dann alle durchstarten
• Deinstallieren des alten Forefront Servers
• Alle Server Zeitverschoben neustarten
• Installieren von Forefront 2010 for Exchange Servers (Auch wieder Zeitverschoben)
• Sofortiges Konfigurieren der Forefronts um den virenfreien Betrieb zu gewährleisten
• Auf jedem Frontend und Cluster Server den Installer 4.5 installieren, wo noch nicht Windows 2008 läuft
• Alle Server Zeitverschoben neustarten
• Active Directory Schema erweitern und aktualisieren (PrepareSchema / PrepareAD)
• Nun die Frontends (CAS und HUBs) nacheinander auf SP2 aktualisieren und durchbooten
• Dann zuerst den B-Node Cluster aktualisieren und durchstarten
• Clusterfailover durchführen, Clusterinhalt Upgraden
• A-Node Cluster aktualisieren und durchstarten
• Clusterfailover zum Test
• Die letzten 4 Punkte nochmals durchführen für das SP2 Rollup 1
• Alles testen (Empfang, Senden, OWA, Viren senden, etc.)

Eine kleine Screen-Auswahl:

Exchange 2007 SP 2 Update	Test Virus
Cluster Node B per Konsole	Yes! We kill spam (und zwar enorm viel!)