Autodiscover bei Outlook abschalten

Die Autodiscover Funktion von Outlook ist eine nützliche Sache, die einen bei gemischten Umgebungen mit mehre Firewalls, DNS- und Exchangeservern in die Verzweiflung treiben kann. Vielleicht hat Microsoft deshalb ja sogar einen Song über Autodicover auf der Technet-Webseite veröffentlicht 😉


http://gallery.technet.microsoft.com/The-Autodiscover-Song-a68b9f7c

Leider läuft ab Outlook 2007 ohne autodiscover einiges nicht mehr (z.B. Free and Busy Informationen, der Abwesenheitsassist, das Offline Address Book usw). Dies lässt sich allerdings umgehen, indem man für den Client das Autodiscover abzuschalten. Im folgenden ein paar Registry-Einträge einem dies ermöglichen:

HKCU\Software\Microsoft\Office\12.0\Outlook\AutoDiscover
DWORD: DisableAutoStartup
Set to 1
HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\12.0\Outlook\AutoDiscover
DWORD: ZeroConfigExchange
Set to 1
2. Free Busy:
Outlook 2007 zwingen den Public Folder Free/Busy zu nutzen:
Key: HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\Options\Calendar
DWORD: UseLegacyFB
Wert:
0 (oder nicht vorhanden) = default Einstellung - Autodiscover nutzen
1 = public folder free/busy nutzen

Outlook 2003 für Exchange 2010 verwenden

Wenn man mit Microsoft Office Outlook 2003 auf ein Microsoft Exchange Server 2010-Postfach zugreift, werden E-Mail die gelöscht oder verschoben wurden noch längere Zeit im Ordner angezeigt. Dies liegt daran, dass Microsoft bei Exchange 2010 keine UDP-Benachrichtigungen mehr an Outlook versendet.

Da sehr viele Kunden noch Outlook 2003 einsetzen, hat Microsoft diese Funktion aber mit „Update Rollup 3 für Exchange Server 2010 Service Pack 1“ wieder ermöglicht. Damit die UDP-Benachrichtigungen wieder gesendet werden, muss allerdings zusätzlich der folgende Registrierungsschlüssel inklusive Subschlüssel erstellt werden:

SubkEy-Speicherort: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeRPC\ParametersSystem
SubkEy-Name: EnablePushNotifications
Typ: REG_DWORD
Wert: 1

Nähere Informationen findet man in dem Microsoft Knowledge Base Artikel 2009942.

Exchange: Autodiscover für externe Clients mit Outlook

Die automatische Konfiguration von Outlook erfolgt ab Version 2007 über die Datei autodiscover.xml. Ein externer Outlook-Client (also einer der nicht in der Domain des Exchangeservers ist) sucht diese Datei im Verzeichnis autodiscover auf einem Server mit dem DNS-Namen autodiscover.[Domain].[TLD]. Wenn ein externer Outlook-Client also mit einem Exchange-Server der Domain microsoft.de aufbauen soll, würde diese unter der URL https://autodiscover.microsoft.de/autodiscover/autodiscover.xml nach seiner Konfiguration suchen.

Eigene SSL-Zertifikate bei Exchange 2007 und 2010

Oft werden für Exchange Server eigene SSL-Zertifikate von thawte/VeriSign, Comodo oder ähnlichen Ausstellern verwendet. Dadurch gibt es bei dem ersten Aufruf von einem Client aus keine lästigen Meldungen, bei denen das „Zertifikat eines unbekannten Ausstellers“ als vertrauenswürdig bestätigt werden muss. Wenn der Exchange-Server im LAN eine anderen Namen oder eine andere Domäne verwendet meldet Outlook nach dem Wechsel des Zertifikates bei jedem Start: „Der Name auf dem Sicherheitszertifikat ist ungültig oder stimmt nicht mit dem Namen der Webseite überein.“ Dies liegt daran, dass der Common Name des Zertifikates nicht dem internen Namen des Exchange-Servers entspricht.

Um das Problem zu lösen muss man in der Exchange Management Shell die folgenden Befehle eingeben (dabei sollten der CAS_Server_Name und die URL natürlich entsprechend angepasst werden):

Set-ClientAccessServer -Identity CAS_Server_Name -AutodiscoverServiceInternalUri https://mail.contoso.com/autodiscover/autodiscover.xml
Set-WebServicesVirtualDirectory -Identity "CAS_Server_Name\EWS (Default Web Site)" -InternalUrl https://mail.contoso.com/ews/exchange.asmx
Set-OABVirtualDirectory -Identity "CAS_Server_name\oab (Default Web Site)" -InternalUrl https://mail.contoso.com/oab
Set-UMVirtualDirectory -Identity "CAS_Server_Name\unifiedmessaging (Default Web Site)" -InternalUrl https://mail.contoso.com/unifiedmessaging/service.asmx

Wobei der letzte Befehlt nur bei Exchange 2007 benötigt wird. Danach sollte man im IIS Manager noch die MSExchangeAutodiscoverAppPool Anwendung im Anwendungspool „Wiederverwenden“ (tolle Übersetzung Microsoft!)

Nähere Informationen sind bei Microsoft im Knowledge Base Artikel 940726 zu finden.

Apache als Reverseproxy für den Webzugriff auf einen Exchangeserver

Um einem Exchangeserver zusätzlich zu schützen kann es sinnvoll sein die Webzugriffe auf diesen über einen Reverseproxy in der DMZ laufen zu lassen. Hierfür eignet sich besonders gut der Apache Webserver, der kostenlos ist und hervorragend als Proxy eingesetzt werden kann. Er kann mit den Modulen alias, headers und proxy und wenigen Zeilen Konfiguration als Reverseproxy eingerichtet werden.

Outlook Web Access über Reverseproxy

Dazu müssen als erstes die Module für den Apache aktiviert werden. Bei Debian kann die mit dem Befehlt a2enmod erfolgen.

Danach müssen zwei virtuelle Hosts konfiguriert werden, welche die Anfragen an den Exchangeserver weiter reichen. Da auch die verschlüsselte SSL-Webseite auf Inhalte der normalen Webseite zugreift, sollte man in jedem Fall auch die normale Webseite einrichten. Die Konfiguration könnte dabei etwa wie folgt aussehen:



   ServerName webmail.example.org
   # This secures the server from being used as a third party
   # proxy server
   ProxyRequests Off

   ProxyVia On

   DocumentRoot /var/www/exchange/
   RequestHeader set Front-End-Https "On"

   ServerName mail.example.com

   #Einträge für Outlook Web Access
   ProxyPass /exchange/ http:///exchange/
   ProxyPassReverse /exchange/ http:///exchange/
   ProxyPass /exchweb/ http:///exchweb/
   ProxyPassReverse /exchweb/ http:///exchweb/
   ProxyPass /public/ http:///public/
   ProxyPassReverse /public/ http:///public/

   #Eintrag für Outlook Mobile Access
   ProxyPass /oma http:///oma/
   ProxyPassReverse /oma http:///oma/

   #Eintrag damit Mobile Endgeräte synchronisieren können
   ProxyPass /Microsoft-Server-ActiveSync http:///Microsoft-Server-ActiveSync/
   ProxyPassReverse /Microsoft-Server-ActiveSync http:///Microsoft-Server-ActiveSync/

   ProxyPreserveHost On



   # This secures the server from being used as a third party
   # proxy server
   ProxyRequests Off

   # Allows the proxying of a SSL connection
   SSLProxyEngine On
   ProxyVia On

   DocumentRoot /var/www/exchange/
   RequestHeader set Front-End-Https "On"

   ServerName mail.example.com

   # Set up SSL to work with this host
   SSLEngine On
   SSLCertificateFile /etc/apache/webmail-proxy/server.crt
   SSLCertificateKeyFile /etc/apache/webmail-proxy/server.key


   #Einträge für Outlook Web Access
   ProxyPass /exchange/ http:///exchange/
   ProxyPassReverse /exchange/ http:///exchange/
   ProxyPass /exchweb/ http:///exchweb/
   ProxyPassReverse /exchweb/ http:///exchweb/
   ProxyPass /public/ http:///public/
   ProxyPassReverse /public/ http:///public/

   #Eintrag für Outlook Mobile Access
   ProxyPass /oma http:///oma/
   ProxyPassReverse /oma http:///oma/
   
   #Eintrag damit Mobile Endgeräte synchronisieren können
   ProxyPass /Microsoft-Server-ActiveSync http:///Microsoft-Server-ActiveSync/
   ProxyPassReverse /Microsoft-Server-ActiveSync http:///Microsoft-Server-ActiveSync/

   ProxyPreserveHost On

Und schon sollte es funktionieren. Bei einem Zugriff auf https://mail.example.com/exchange/ sollte man den Outlook Webaccess zu fassen bekommen (natürlich nur, wenn auf dem Exchangeserver auch ein OWA installiert und konfiguriert ist und der DNS-Eintrag auch wirklich auf den Apache zeigt).

„Senden an“ E-Mail-Empfänger funktioniert nicht bei Outlook und 64 Bit

Microsoft hat mir jetzt bestätigt, dass „Senden an“ bei Windows 2003 mit 64 Bit und Office 2003 oder 2007 nicht funktioniert. Ich hatte zu diesem Problem vor über zwei Wochen eine Anfrage an den Support von Microsoft gestellt. Leider wird es auch kein Update geben, dass dieses Problem behebt. Microsoft scheint eine Problemlösung zu riskant zu sein. Durch eine Behebung des Problems könnte schließlich eine neue Fehlfunktionen verursacht werden.

Das ganze scheint mir eine neue und sehr interessante Variante von „This bug is a feature“ zu sein.

Bei Microsoft formuliert man das übrigens so:

Fuer dieses Problem wird aus folgenden Gruenden kein Hotfix entwickelt:

Wir haben diese Entscheidung sorgfältig überdacht und es wurden bereits diverse Workarounds untersucht wie etwa den Outlook 2003 32bit Registry Schlüssel unter dem 64bit Hive zu registrieren. Alle diese Tests scheitern an der 64bit Architektur und der 32bit Applikation Redirection. Leider gibt es von Office 2003 und 2008 keine 64 bit Version und damit auch keine 64bit MSMAPI.DLL. Dies bedeutet selbst wenn Sie die 32 bit MSMAPI.DLL unter Windows im 64bit Schlüssel registrieren wird der 64bit Explorer niemals eine 32bit DLL laden können. Wir haben dieses nach dem Release von Windows 2003 64bit erkannt und entsprechend das Design der Nachfolgearchitektur (Vista und Windows 2008) geändert. Diese Änderung ist leider nicht trivial und bedeutet für Windows 2003 64bit im Nachhinein einen sehr riskanten Fix welcher alle 32bit Applikationen beeinflussen könnte. Der Workaround aus 32bit Outlook heraus eine Mail zu öffnen und die Datei anzuhängen erscheint uns am einfachsten umzusetzen und völlig risikolos.

Zumindest mußte ich für die Support-Anfrage bei Microsoft nichts bezahlen, da das Problem ein Softwarefehler ist. Man muss ja immer die positiven Dinge im Leben sehen!