Outlook Webzugriff
Der Outlook Webzugriff bietet jedem handelsüblichen, halbwegs aktuellen Browser einen Zugriff auf den kompletten Informationsspeicher von Exchange 2000 per HTML. Wenn der Browser moderne Techniken (DHTLM, WebDAV etc.) unterstützt, steigt die Funktionalität weiter an. Bei geeigneter Anbindung des Exchange Servers können Sie mit jedem Browser in der Welt auf ihr Postfach und andere Informationen im Speicher zugreifen. Lesen Sie auch die Hinweise auf MSXFAQ - Frontend Backend Konstellation.
Detailbeschreibungen je Version :
- OWA 5.5
- OWA 2000
- OWA 2003
- OWA 2007
- OWA 2010
- OWA 2010 Mini
- OWA Formbased
- OWA URL
- OWA Absichern
-
Outlook Edge Addon
Ein Outlook Add-On fpr Edge erlaubt schnellen Zugriff auf ihr Online Postfach
Zusätzlich hat Lee Derbyshire zwei weitere OWA-Zugriffe entwickelt (kostenpflichtig) die aber aufgrund der Funktionsweise hier herein passen und auf OWA für PDA beschrieben sind. Die Freeware OWANotify erlaubt ihnen sogar unter Windows ein kleines Taskicon, um ihren Posteingang zu überwachen.
OWA und Internet
Um Outlook Web Access aus dem Internet zu nutzen, müssen Sie natürlich OWA aus dem Internet erreichbar machen. Und es ist sicher nicht gut, einen Windows Server ganz schutzlost direkt mit einer offiziellen IP-Adresse an mit dem Internet zu verbinden. Auch wenn Windows Server und Exchange mit jeder Version immer sicherer wird, sollte ein gewisser Schutz entsprechend den Firmenanforderungen gewährleistet sein. Dazu zählt natürlich immer ein sicheres öfter geändertes Kennwort und eine zwingende Verschlüsselung per SSL. Auch eine Überwachung auf versuchte Einbrüche und Kennwort-Versuche sollte dazu gehören. Die eigentliche Anbindung trenne ich gerne in drei Stufen auf, von der natürlich die höchste Stufe erreicht werden sollte. Sie sollten zumindest die Risiken und Einschränkungen der schwächeren Ausbaustufen können.
- Stufe 0: Direkt oder NAT
Es gibt wirklich Firmen, die ihren Exchange Server mit IIS direkt am Internet betreiben oder per NAT über einen Router veröffentlichen. Der Schutz besteht maximal in Portfiltern, damit nur der Port 80 oder 443 des IIS erreichbar ist. Da der SSL-Tunnel direkt am Server endet, gibt es keine Gelegenheit einer vorherigen Prüfung der Anmeldedaten (Preauthentication) oder der übertragenen Inhalte (URL-Filterung oder Content-Filterung). Trotzdem sind wohl sehr viele Server so angeschlossen und solange auf dem IIS keine unsicheren Skripte installiert wurden. - Stufe 1: "Webveröffentlichung"
Hierbei nimmt ein vorgeschaltetes System die Anfragen per HTTPS an, d.h. aus dem Internet glaubt man einen Webserver zu sehen, der aber die Daten entschlüsselt und nur ausgewählte URLs nach intern durchlässt. Neben der Verlagerung der Verschlüsselung und der Möglichkeit, die verschiedenen URLs auch an andere internen Systeme zu leiten (ähnlich einem Portal) verhindert die selektive Veröffentlichung von URLs eine gute Absicherung der internen Server. Wenn auf einem internen Webserver eine neue Anwendung installiert ist, dann ist sie eben nicht automatisch auch aus dem Internet erreichbar. Natürlich sieht Microsoft den ISA-Server als passendes System an. Aber auch andere Firewalls erlauben zumindest die Veröffentlichung und Filterung von URLs. Selbst ein Apache kann als Reverse Proxy dienen (Siehe auch WebProxy) - Stufe 2: Zusätzliche Authentifizierung
Stufe 2 kann noch verbessert werden, indem die Anmeldung schon durch das vorgelagerte System erfolgt. ISA2006 kann sogar die Formulare von OWA nachbilden und leitet die Anfragen erst nach erfolgreicher Anmeldung an den Exchange Server im Hintergrund weiter. Dies entlastet und sichert OWA zusätzlich für überflüssigen anfragen. Einige Produkte schalten hier sogar eine starke Authentifizierung (z.B. Smartcard, Token o.ä.) dazwischen, so dass der Anwender erst nach dieser Anmeldung Zugriff auf OWA erhält. Allerdings muss man dazu auch sage, dass z.B. ActiveSync solche Vorschaltseiten erst seit Windows Mobile 6 unterstützt und einige Einschränkungen gelten.
Welche Absicherung Sie letztlich verwenden ist von ihren persönlichen Vorlieben und Sicherheitsanforderungen abhängig.
Funktionsweise
Der Zugriff auf den Informationsspeicher mit Exchange 2000 unterscheidet sich grundlegend von der Realisation mit Exchange 5.5. Im Gegensatz zu Exchange 5.5, wird hier der Zugriff nicht per ASP-Seiten realisiert, die nur bedingt skalierbar waren und relativ langsam funktionierten oder auch nicht funktionierten.
Der Outlook Webzugriff von Exchange 2000 wird durch eine ISAPI-DLL realisiert, die auf dem lokalen Webserver mit integriert wird. Die Funktion dieser Integration ist außerordentlich wichtig, da viele Programme (auch der Exchange Systemmanager) den Zugriff per HTTP z.B.: zur Verwaltung von Ordner verwenden.
OWA 2000 funktioniert nur direkt auf einem Exchange Server. Eine Trennung wie bei OWA 5.5 ist hier nicht möglich. Aber nicht jeder möchte, dass der gleiche Rechner, welcher produktiv das firmeninterne System auf Basis von Exchange 2000 betreibt, auch über das Internet erreichbar ist oder extreme Verwendung des Webzugangs das Gesamtsystem Ausbremst. Daher ist es möglich, auch den Outlook Webzugriff vom eigentlichen Exchange Server zu verschieben auf so genannte Frontendserver. Dies sind ebenso Exchange Server, die aber keinen eigenen Informationsspeicher betreiben. (Exchange Enterprise notwendig). Dann können mehrere dieser Frontendserver z.B. in einer DMZ (siehe Firewall) betrieben werden und so die Last verteilen und der Backendserver übernimmt nur noch die Speicherhaltung, eventuell abgesichert durch den Betrieb in einem Cluster.
Sichern und Installation
Die Installation ist sehr einfach, denn Sie haben keine Wahl, Exchange 2000 ohne OWA zu installieren. Auf dem Windows 2000 Server muss zur Installation von Exchange 2000 zwingend der NNTP-Dienst, der SMTP-Dienst und der Internet Information Server installiert sein. Selbst bei minimaler Installation wird dann OWA automatisch mit installiert.
Aber sie sollten ihren IIS-Server sichern. Ideal ist es, vor der Exchange Installation den IIS entsprechend zu sichern. Dazu gehören auch die aktuellen Hotfixe und Updates.
- IIS auf eine eigene Partition installieren
- Anwendern von Paketfiltern um unbenutzte Ports zu blockieren
- Weiterhin sollten dann auch die überflüssigen Verzeichnisse wie IISADMIN, PRINTERS, IISSAMPLES, etc. entfernen.
- Keine FrontPage Erweiterungen oder WebDav auf dem Produktionsserver
- Deinstallieren bzw. Deaktivieren Sie alle überflüssigen Dienste und Windows Komponenten
- Entfernen Sie alle nicht notwendigen ISAPI Zuordnungen
- Setzen Sie die Rechte für den IIS-Dienstaccount auf ein Minimum. Wenn Sie keine Skripte nutzen, dann muss auch kein Recht zur Ausführung existieren
- Setzen Sie NTFS-Berechtigungen
- Wenn Sie ASP-Dateien nutzen, dann hinterlegen Sie dort keine sensitiven Daten.
- Setzten Sie den Parameter für "MaxClientRequestBuffer" (siehe Q260694"
- Wenden Sie IISLOCKDOWN an.
Viele dieser Aktionen werden mittlerweile von IISLOCKDOWN selbst durchgeführt. Interessant kann es auch sein, die Default Webseite komplett zu löschen oder auf eine interne Netzwerkkarte zu verbinden und die OWA-Seite zum Internet als eigene exklusive Webseite zu betreiben. Dann werden auch spätere Installation, die in der "Default Seite" Änderungen vornehmen nur intern exponiert
- Q309508 XCCC: IIS Lockdown and URLscan Configurations in an Exchange Environment
- Q313131 IISLOCKDOWN und Exchange
- In folgenden Whitepaper finden sie weitergehende Informationen zur
Sicherung des IIS 5.0
http://www.Microsoft.com/germany/ms/technetdatenbank/overview.asp?
siteid=511888
Konfiguration
Zu konfigurieren gibt es beim OWA2000 fast nichts. Im Gegensatz zum OWA 5.5 können sie keine ASP-Seiten mehr verändern. Allenfalls einige Icons können Sie gefahrlos ihrem eigenen Geschmack anpassen, um damit das Gesamtaussehen ihres OWA-Zugang etwas anzupassen.
- Betriebssystem sichern
Sichern Sie Windows 2000. Installieren und starten Sie nur Dienste, die wirklich notwendig sind. Ein Dienst, der nicht installiert ist, kann nicht missbraucht werden. Stellen Sie den Server auch in eine , dessen Schwäche kann auch nicht ausgenutzt werden. Es versteht sich von selbst, dass zumindest ein Portfilter den Server gegen das Internet unddas interne LAN sichern sollte. Siehe Exchange und Firewalls. - IIS sichern
Sichern Sie die Basisfunktion des Webservers, indem Sie jeden Ballast und zusätzliche Funktionen entfernen oder deaktivieren. - Lokale Anmeldung oder nicht ?
Beim Exchange 2000 ist im Gegensatz zu OWA 5.5 keine Anmeldung mehr auf dem Mitgliedsserver notwendig. (Q311422 XCCC: "Log On locally" right not required für Exchange 2000 OWA), weil die Anmeldung über das Netzwerk per Default erteilt ist und genutzt wird. Dies ist aber nur die halbe Wahrheit. Sobald ein "nicht XML tauglicher" Browser (NS3/4/6, Opera,IE3/4) auf OWA2000 zugreift, dann läuft die komplette Anwendung auf dem Server und die lokale Anmeldung ist weiterhin notwendig. Wenn der OWA-Server ein Domain Controller ist, dann braucht der Benutzer ebenso das Recht der lokalen Anmeldung. - Logo links oben anpassen
http://servername/exchweb/img/logo-ie5.gif
Dies ist die URL zu dem Logo links oben über der Navigationsleiste, wenn sie einen IE5 einsetzen. Es ist 148x38 Pixel groß. Sie können es z.B.: durch ihr Firmenlogo ersetzen. Der Tabellenhintergrund ist Gelb und sollten Sie anpassen, wenn Der Anwender die Navigationsleiste breiter zieht. Dies geht am besten über die CSS-Vorlage. - Design anpassen
http://servername/exchweb/controls/navbar.css
Dies ist die Formatvorlage, welche dem Browser das Design und die Farben mitteilt. Hier können sie das allgemeine Aussehen des OWA-Zugang anpassen. - Anmeldeoptionen einstellen
Wenn Sie mit NetScape oder anderen Browsern arbeiten, dann sollten Sie auf der Karteikarte "Verzeichnissicherheit" bei der Anmeldung auch die Klartext/Basic-Anmeldung erlauben. Nur der Internet Explorer versteht NTLM als Authentifizierungsverfahren. - Verschlüsselung optional aktivieren
Denken Sie über SSL nach, damit bei einer Klartextanmeldung die Kennworte verschlüsselt sind - Sicherheitsrichtlinien einstellen
Beim Exchange 2000 ist im Gegensatz zu OWA 5.5 keine Anmeldung mehr auf dem Server notwendig. (Q311422 XCCC: "Log On Locally" right not required für Exchange 2000 OWA
Wenn ihr OWA-Server aber zugleich Domaincontroller ist, dann brauchen Sie das Recht trotzdem.
Weitere Anpassungen können Sie gerne versuchen. Es empfiehlt sich immer eine Kopie des Originals zurückzuhalten und die Änderungen auf mehreren Browsern zu testen.
Webbasierte Administration
Seit Mai 2004 gibt es sogar eine webbasierte Administration für OWA
- Exchange 2003: Outlook Web Access Web Administration
http://www.Microsoft.com/downloads/details.aspx?FamilyID=4bbe7065-a04e-43ca-8220-859212411e10&DisplayLang=en
Erweiterte Nutzung
Eigentlich gibt es nicht viel hierzu zu sagen. erinnern sie sich immer daran, dass sie jedes Objekt, jede Ansicht, jeden Ordner direkt als URL adressieren können. Es steht ihnen nun frei, in ihrer eigenen Intranetseite, z.B. eine eigene Frameseite aufzusetzen, und in einem der Fenster einen passenden Ordner einzublenden.
- Direkter Zugriff auf den Posteingang
http://servername/exchange/Username - Direkter Zugriff auf die eigenen Kontakte
http://servername/exchange/Username/Kontakte/?Cmd=contents
Durch die direkte Authentifizierung über den IE gelten als Zugriffsrechte die gleichen Rechte, die der Anwender mit Outlook im LAN hat. Kniffliger wird es erst, wenn der lokale PC nicht der Domäne oder einer vertrauten Domäne angehört oder wie Windows 9x oder älter nichts von Domänen versteht. Dann muss der Anwender sich manuell anmelden.
Sie sollten aufpassen, wenn Sie später die IP-Adresse des Servers ändern oder weitere Webseiten installieren, damit der Zugriff auf die Virtuellen Verzeichnisse möglich bleibt. Ansonsten werden Sie auch mit der Administration ihre Probleme bekommen. OWA nutzt den Hostnamen samt Domäne, welche Sie mit übermitteln. Achten Sie daher darauf, dass beim Zugriff auf den einfachen Servernamen auch die virtuelle Webseite erreicht wird, in der die Exchange Verzeichnisse existieren. Wenn der Server über weitere IP-Adressen und Aliasnamen (CNAME) im DNS mehrere virtuelle Webseiten betreibt, dann sollte der eigentliche Hostname auf der Default Webseite verbleiben. So sollten nach jedem Schritt bei der IIS Konfiguration die Funktion von OWA aber auch des Exchange Systemmanagers im Hinblick auf die Verwaltung z.B. öffentlicher Ordner kontrollieren.
OWA und hohe Sicherheit
Immer wieder kommt die Frage, wie "sicher" OWA eigentlich ist. Gibt es High Security Konzepte für OWA? Wie sichern sich wirklich kritische Bereiche, z.B. Forschung und Entwicklung, Banken und andere.
Klar ist, dass hierbei zum einen das System selbst gesichert werden muss aber auch die Anmeldung zu betrachten ist. In vielen Umfeldern ist der Zugang mit Benutzername und Kennwort nicht ausreichend sicher. Solche Daten können Abgefangen oder veruntreut werden. Bei "hochsicheren" Umgebungen ist es daher hilfreich, mehr als nur Username/Kennwort zu machen.
Client Zertifikate sind aber auch kein idealer Weg, weil diese kaum jemand "mitnimmt" und auf Internetsystemen das nichts bringt. Da helfen dann auch keine USB-Keys etc. Hier ist dann RSA und andere gefragt, d.h. die kleinen Chipkarten/Dongles, die alle 20 Sekunden einen anderen "Einmalkennwort" generieren. Den kann man in die IIS Anmeldung mit einbeziehen, oder über den Reverse-Proxy vorschalten. das machte ich bei "kritischen" Kunden, d.h. der User geht per OWA auf "ihren" Server und die Checkpoint fängt den Zugriff ab und leitet den Anwender erst mal auf eine Anmeldeseite über den ACE Server weiter. Der User meldet sich also mit Username und Token an und erst dann lässt die Firewall diesen User auf ganz bestimmte Dienste zu.
Frontend/Backend ist kein Aspekt der Sicherheit, sondern eine Funktion, wenn man mehrere Backendserver hat und diese alle unter "einem" Namen veröffentlichen will. Es erlaubt einiges aber FE/BE ist nicht sicherer als ein BE alleine. Es sei denn man nutzt den FE und macht ihn sicherer durch weniger Dienste und einen zugestopften IIS, den Backend kann/will man ja vielleicht nicht wirklich "zustopfen"
Wie ist das mit Daten, die auf einem Client im Internetcafe zurückbleiben? Schreibt der IE lokal Daten die jemand anderes weiter verwenden könnte? Im Prinzip cachen Browser Daten, damit diese schneller wieder angezeigt werden. Speziell wenn z.B. Bilder mehrfach verwendet werden. Aber OWA liefert die Daten erst mal "non Cachable" aus und zudem sorgt SSL dafür, dass die Daten normal nicht gecached werden. Ich kann in meinem Cache keine Daten meines OWA-Zugiffs finden und ein Proxy beim Provider kann auch nicht viel Cachen, wenn ich SSL einsetzen. Dies ist natürlich sehr anzuraten. Sie sollten aber am Ende den Browser wirklich schließen oder anderweitig die Verbindung abbauen, damit auch die gecachte Anmeldung des Browsers nicht mehr greift und kein fremder Benutzer mit "ZURÜCK" wieder ihre Sitzung aufnimmt.
Damit ist mal eigentlich sehr sicher. Sicherheit ist aber ein Prozess, der permanent kontrolliert und angepasst werden muss. Dazu gehört auch die Überwachung des Zugriffs um Anomalien zu erkennen und stoppen zu können Ebenso müssen Sie natürlich ihre Anwender immer wieder informieren. OWA ist sicher, aber wenn ein Trojaner beim Anwender einfach den kompletten PC fernsteuert, dann ist auch dies kein sicheres System mehr.
OWA und NLBS
Folgender Microsoft Artikel bietet hinweise, wie Sie mehrere Outlook Web Access Server als Frontendserver unter einer IP-Adresse veröffentlichen und damit ein Failover erhalten.
"Der Microsoft Windows-Lastenausgleichsdienste (Windows Load Balancing Service, WLBS) ermöglicht das Ausgleichen von Serverlasten für eingehende Clientverbindungen. Microsoft Outlook Web Access (OWA) kann in Verbindung mit WLBS verwendet werden, um die Verarbeitung des Datenverkehrs von eingehenden Webclientverbindungen auf einem Microsoft Exchange Server-Computer zu verwalten.
- In diesem Dokument ist ein Testszenario
beschrieben.
http://www.Microsoft.com/germany/ms/technetdatenbank/overview.asp?siteid=539921 - Network Load Balancing
Mehrsprachigkeit
Outlook Webzugriff 5.5, 2000 und 2003 sind von Hause aus mehrsprachig installiert. Die Filter-DLL im Webserver erkennt anhand der Sprache des Clients (der Browser), und schaltet dann die Sprache ein. Sie könne auf dem Client die Sprache im Browser ändern.
Sicherheit mit SSL
Der Zugang per OWA ist ein öffentliches Protokoll. HTTP ist ein Standard und ohne besondere Vorkehrungen "Klartext". Dies bedeutet, dass auch ihre Anmeldung im "Klartext" über die Leitung gesendet wird. Dies kann natürlich nicht ihr Ziel sein. Daher sollten Sie umgehend die Verschlüsselung per SSL auf dem Webserver aktivieren.
- 218445 How to Configure Certificate Server für use with SSL on IIS
- 228991 How to Create and Install an SSL Certificate in Internet Information Server 4.0
- 234022 XCLN: Configuring Exchange OWA to use SSL
- 257591 Description of the Secure Sockets Layer (SSL) Handshake
- 268822 XWEB: OWA How to Redirect http://<server_name>/exchange Users to use https:// Prefix
- 290051 Troubleshooting von "Page cannot be displayed":
- 298805 HOW TO: Enable SSL für All Customers Who Interact with Your Web Site
- 299525 HOW TO: Set up SSL using IIS 5.0 and Certificate Server 2.0
- 299875 HOW TO: Implement SSL on a Windows 2000 IIS 5.0 Computer
- 320291 XCCC: Turning on SSL für Exchange 2000 Server Outlook Web Access
- 234022 XCLN: Configuring Exchange OWA to use SSL
- 327544 How to configure SSL connections to Outlook Web Access in Small Business Server 2000
- 823024 HOW TO: Configure Certificate Services and OWA in SBS 2000
- 830827 How to use forms based authentication with Outlook Web Access clients in Exchange Server 2003
- 821900 How to open another User's calendar by using Exchange Server 2003 Outlook Web Access
- Checkliste für IIS 5.0. In diesem Whitepaper erhalten Sie eine
grundlegende Sicherheitscheckliste für den IIS 5.0. Sie erfahren, was
bei der Konfiguration zu beachten ist und anderes Wissenswertes zu den
Einstellungen von IIS.
http://www.Microsoft.com/germany/ms/technetdatenbank/overview.asp?
siteid=511888 - Microsoft Root CA Program
http://msdn.Microsoft.com/library/?URL=/library/en-us/dnsecure/html/rootcertprog.asp - SSL Exploit April 2004
Deutsch: http://www.Microsoft.com/germany/ms/technetservicedesk/bulletin/bulletinMS04-011.htm
Englisch: http://www.Microsoft.com/technet/security/bulletin/ms04-011.mspx
Links auf Workaround zum Schließen der Schwachstelle ohne das Sicherheits-Update zu installieren:
Deutsch: http://www.Microsoft.com/germany/ms/security/pctdisable.mspx
Englisch: http://www.Microsoft.com/security/incident/pctdisable.asp
Der Einsatz von SSL löst auch das Problem mit vielen Proxy Servern. Da Proxy Server kein SSL cachen können (wäre ja sinnlos) wird es meist 1:1 durchgeschleust. Damit fallen all die Fehler nicht auf, bei denen ein Proxy die neuen Funktionen (WebDAV) nicht versteht.
Passwort ändern
Der OWA 2000 bringt im Gegensatz zum OWA von Exchange 5.5 keine eigenen Routinen mehr mit, um Kennworte zu ändern. Statt dessen baut OWA auf die Existenz der URL https://servername/IISADMPWD auf. Diese Skript sind bei der Installation von Windows 2000 Server auf dem Server vorhanden, aber nicht eingerichtet. Siehe IISADMPWD.
OWA 2007/2010 bringen schon eine eigene Funktion mit, um ein Kennwort zu ändern. Dies funktioniert aber nur, wenn Sie sich
noch an OWA anmelden können. Wenn ihr Kennwort schon abgelaufen ist oder
Sie das Kennwort bei der Erstanmeldung ändern müssen, dann benötigen Sie
weiterhin IISADMPWD.
- What you need to know about the OWA Change Password feature of Exchange
Server 2007
http://blogs.technet.com/b/exchange/archive/2008/12/09/450238.aspx - Password Reset Feature in Exchange 2007 and 2010
http://www.ucblogs.net/blogs/exchange/archive/2010/11/08/Password-Reset-Feature-in-Exchange-2007-and-2010.aspx -
So you want to change your expired passwords in OWA...
http://blogs.technet.com/b/exchange/archive/2010/10/06/456520.aspx
Wenn Sie ihren OWA-Zugang per ISA/TMG absichern, können Sie auch dort die Funktion auf dem FBA-Listener aktivieren.
- 957859 The "change password" feature does not work as expected after you install ISA Server 2006 Service Pack 1
Fehler bei der Anmeldung
Oft scheint alles zu gehen, aber nur der Administrator kann OWA nutzen. Letztlich liegt das eher an Problemen mit der Anmeldung am OWA durch mangelnde Rechte oder falsche Konfiguration.
Als Standard kann sich ein Anwender am OWA2000 nur per NTLM-Autorisierung anmelden. Dummerweise geht die nicht durch Proxy Server hindurch und wird auch von Browsern wie NetScape oder Opera einfach nicht unterstützt. Schade, aber diese Browser unterstützen "Klartext" als Anmeldung. Daher ist diese Möglichkeit auf dem virtuellen Verzeichnis erst freizugeben. Denken Sie aber daran, bald auf SSL umzustellen, da dieses Kennwort ihr Domainkennwort ist und damit OWA als "schwaches Glied" in der Kette ihre Sicherheit reduzieren könnte.
Weiterhin gibt es ein generelles Problem wenn der Exchange 2000 Server zugleich auch Domain Controller ist. Durch die Sicherheitsrichtlinien ist festgelegt, dass sich Anwender nicht auf Domain Controllern anmelden dürfen. Soweit so gut aber es geht trotzdem meistens, nämlich dann, wenn der Anwender einen Internet Explorer 5 oder neuer verwendet und damit WebDAV zum Einsatz kommt. Dann meldet sich der Benutzer eigentlich gar nicht "interaktiv und lokal", sondern greift nur per WebDAV auf die Objekte zu.
Die Anmeldung "auf dem Server" passiert aber immer dann, wenn der Benutzer einen anderen Browser nutzt, weil dann OWA erkennt, dass WebDAV nicht genutzt werden kann und schaltet auf eine andere Steuerung um. Zur Nutzung dieser benötigt der Anwender aber entsprechende Rechte. Ob sie ihm diese geben wollen (er könnte ja dann auch am Server sich anmelden und die Rechte auf Freigaben umgeben) oder nicht, bleibt ihnen überlassen.
Fehler beim Bildaufbau
Meist sind die Fehler, die beim Einsatz des OWA2000 mir gemeldet werden, keine Exchange 200 Fehler, sondern in anderen Ursachen begründet. Die Hitliste führen hier natürlich die Namensauflösung an. Ebenso die Authentifizierung (NTLM oder Basic) und der Einsatz von Proxy Servern. Schalten Sie einfach den Proxy intern aus, wenn Sie den Exchange Server verwalten. Wenn die Administration oder Zugriff dann möglich ist, dann verhindert ihr Proxy oder eine entsprechende Einstellungen die Funktion. Häufige Fehler sind z.B.: dass der Proxy selbst andere DNS-Server (z.B. externe Systeme) nutzt und damit interne Systeme nicht auflösen kann.
Für den Zugriff von extern hilft das natürlich nicht weiter, da sie hier entweder einen Proxy brauchen um überhaupt an den Exchange Server zu kommen oder der Zugangsprovider (Mobilcom etc.) einfach alle Surfer-Daten zwangsweise auf einen Proxy umleiten.
Aber leider unterstützen nicht Proxyserver die HTTP-Protokollfunktionen (HTTP 1.1) oder blockieren diversen Anmeldeverfahren (NTLM). Dann bleibt nur der Weg SSL zu nutzen oder einen anderen Provider oder Port. Wenn Sie im LAN ohne Proxy auf OWA kommen, dann sollten Sie nicht weiter bei Exchange suchen, sondern sich in die Richtung Windows NT, TCP/IP, Namensauflösung, Firewall etc. bewegen.
Oftmals macht ihnen aber auch ihr Client einen Strich durch die Rechnung, wenn er den Zugriff auf den Exchange Server nicht als "Intranet" erkennt, sondern über den Proxy als "Internet" oder "unsicheres LAN" definiert. Dann verhindert der aktuelle IE5.5 gerne die Funktion einige JavaScript-Funktionen, welche über Fenstergrenzen hinweg greifen. Das bemerken Sie z.B. daran, dass die keine öffentlichen Ordner in der Navigation erreichen können. Fügen Sie in diesem Fall z.B. den Exchange Server in die Liste der vertrauenswürdigen Systeme hinzu und starten Sie dann den Internet Explorer neu, dann funktioniert der Zugriff. Das ist natürlich nur eine schnelle Abhilfe und keine firmenweite Lösung. Hier sollten Sie über Richtlinien und ein zentrales Management der Browser nachdenken.
- WebProxy
- 280823 Troubleshooting OWA when the contents frame displays "Loading"
- 296232 XCCC: Empty Inbox using Internet Explorer 5 and later für OWA
- 301017 Users Cannot Access OWA using Versions of IE 5.0 or newer
- 320202 How to remove and reinstall IIS and Exchange
- 328663 XCCC: Outlook Web Access Does Not Show Contents of Inbox or Other Folders
- 843093 How to troubleshoot IIS metabase corruption on a Windows 2000 Server-based computer that is running Exchange 2000 Server or Exchange Server 2003
- 910119 Users receive a "Loading" message when they use OWA to access their mailbox after you apply a hotfix or a service pack to Exchange Server 2003
- 262181 Virtual Internet Information Server directories used by Outlook Web Access
Manchmal kann es aber auch einfach ein Problem der "Frontend/Backend-Konfiguration" sein, die Bereiche "drum herum" kommen überwiegend vom Frontend Server (z.B. alles aus ExchWeb), wären die Inhalte von Frontend beim Backend abgerufen werden. Kann hier des Frontend den Backend nicht richtig auflösen oder machen SSL oder Hostheader einen Strich durch die Rechnung, dann sehen Sie auch keine Inhalte.
Hierzu zählt auch, dass der Zugriff auf "/EXCHWEB" per Default "anonym" erfolgt. Wenn sich, warum auch immer, aber das Kennwort der IUSR-Kontos auf dem lokalen PC nicht mehr mit dem im IIS hinterlegten Kennwort übereinstimmt, dann ist der Effekt ebenfalls vorhanden, da der Client keine Javascripte und Icons laden kann.
Einfacher Test: Surfen sie auf
http://ihr.exchange.name/exchweb/img/form-find-animated.gif
Der Zugriff sollte ohne Anmeldung möglich sein und ihnen die animierte Lupe anzeigen. Ansonsten ist entweder ""anonymous" nicht aktiviert, die NTFS-Rechte auf dem Verzeichnis (z.B. C:\Programme\Exchsrvr\exchweb\img\form-find-animated.gif)verändert oder der lokale User "IUSR_servername" kann sich nicht anmelden.
showiispasswords.vbs.txt
VBScript zum Ausgehen der IIS-Kennworte in der Metabase. Diese können
dann auf den lokalen Benutzern gesetzt werden
Eine kleinere Version des Skripts gibt es auch noch:
Option Explicit Dim objIIS, strMessage Set objIIS = GetObject ("IIS://localhost/w3svc") WScript.Echo "anonymous credentials in the metabase are:" WScript.Echo "AnonymousUserName = " & objIIS.Get("AnonymousUserName") WScript.Echo "AnonymousUserPass = " & objIIS.Get("AnonymousUserPass") Set objIIS = Nothing
Alternativ können Sie auch im IISLOG sehen, dass die Zugriffe auf /EXCHWEB/* fehlschlagen.
OWA mit SSL und Umleitung
Oftmals ist es zu aufwendig für Anwender die URL komplett einzugeben. Dann bietet sich ein Alias im Internet an, so dass der Zugriff z.B.: über http://owa.firma.de möglich ist. Dazu muss auf diesem Webserver dann eine Default-Seite liegen, die den Anwender direkt umleitet.
z.B. eine Datei mit folgendem Inhalt:
<html> <head> <meta HTTP-EQUIV="Pragma" CONTENT="no-cache"> <meta HTTP-EQUIV="Expires" CONTENT="now"> <meta http-equiv="refresh" content="0; URL=/exchange"> <title>OWA Umleitung</title> </head> <body> Moment bitte, Sie werden umgeleitet </body>
Denkbar ist hier natürlich auch eine Umleitung auf HTTPS. ähnliche Umleitungen sind aber auch mit dem IIS direkt konfigurierbar oder die 403.4-Fehlerseite (SSL-required) wird entsprechend zu einer Umleitung. Damit wird ein SSL-Zwang für den Anwender gar nicht groß sichtbar.
- Vereinfachen des Outlook Web Access-URL
http://technet.microsoft.com/de-de/library/aa998359(v=exchg.80).aspx - Q268822 XWEB: OWA How to Redirect http://<server_name>/exchange Users to use https:// Prefix
- http://de.wikipedia.org/wiki/Weiterleitung
-
The One With The FBA Redirect Loop
https://blogs.technet.microsoft.com/jasonsla/2015/01/15/the-one-with-the-fba-redirect-loop/
Exchange mag keine CNG Zertifikate
OWA2003 und SharePoint Team Services
Outlook Web Access ist im Prinzip sehr robust, aber beim Einsatz auf Windows 2003 Server sind Anpassungen notwendig, damit auch mit den mittlerweile verfügbaren Team Services die Funktion gewährleistet ist.
- OWA2003 Q823265 "Page Not Found" Error Message When You Browse Exchange Server 2003
- Troubleshooting Microsoft Exchange System Manager Public Folder
Expansion Problems
http://technet.microsoft.com/en-us/library/aa996098.aspx
Sharepoint und Exchange 2007 Koexistenz - 282125 You receive an "80040E19" error message when you try to connect to public folders by using Exchange System Manager
Auch wer den Microsoft Software Update Service (SUS) installiert, wird feststellen, dass SUS mit dem Programm IISLOCKDown (IISLOCKD) einige Funktionen des IIS deaktiviert und damit Outlook Web Access außer Funktion setzt.
OWA Anpassungen
Microsoft Outlook Web Access kann in gewissen Grenzen an die eigenen Bedürfnisse und Layoutwünsche angepasst werden. Während OWA 5.5 fast nur aus ASP-Seiten besteht und damit fast in jeder Hinsicht angepasst werden kann, so besteht der OWA von Exchange 2000 und Exchange 2003 aus einem ISAPI-Filter, der nicht zu verändern ist und einigen Dateien, die im virtuellen Verzeichnis "ExchWev" (meist auf Programme\Exchsrvr\Exchweb) liegen und angepasst werden kann. So lassen sich zumindest die Icons und die Farben (über Style Sheets, CSS) anpassen. Allerdings sollten Sie dabei einige Randbedingungen beachten
- Servicepacks und Updates nehmen keine Rücksicht
Wann immer Sie ein Service pack installieren, werden die bestehenden Dateien durch neue oder originale Versionen ersetzt. Sie sollten daher ihre Veränderungen sauber dokumentieren und sichern, um diese nach dem Update wieder einspielen oder wieder herstellen zu können - Begrenzter Support
Wenn sie nicht nur Grafiken, sondern auch die Skripte (JS) und andere aktive Komponenten verändern, dann kann Microsoft aber auch ein anderer Dienstleister nur noch schwer bei Fehlern unterstützen. - 327178 Microsoft support policy für the customization of Outlook Web
Access für Exchange
Dies ist die Microsoft Policy für Änderungen an OWA.
Einige weitere Hinweise zum Anpassen von OWA finden sie auf den jeweiligen Detailseiten:
OWA Erweiterungen durch Dritthersteller
Auch wenn OWA mit jeder neuen Version und Service Packs von Exchange immer leistungsfähiger und besser wird, so bleibt immer noch viel Platz für Dritthersteller, die OWA erweitern.
-
http://www.messageware.com/
Erweitert Outlook Web Access um AttachmentViewer, Kontakte aus öffentlichen Ordnern, Policies und Customizing