Outlook Webaccess Exchange 5.5

Wichtiger Patch:
Wenn Sie Outlook 2003 einsetzen, kann OWA 5.5 hängen bleiben. Details:
818709 Outlook Web Access Stops Responding When You Try to Access a Mailbox on an Exchange 5.5 Computer

Outlook Web Access ist das Modul, um per Webbrowser von überall auf dem Internet schnell auf die eigene Seite zugreifen zu können. So nett das ist, es gibt immer wieder Fragen und Probleme dazu. Mit dem Outlook Webzugriff können sie übrigens auch weiterhin auf einen Exchange 2000 Server zugreifen. Aber im Hinblick auf die Funktionen des OWA 2000 sicher nur für den Zeitraum der Migration.  Lesen Sie auch die Hinweise auf MSXFAQ - Frontend Backend Konstellation.

Funktionsweise

Der Outlook Web Zugriff von Exchange 5.5 ist ein virtuelles Verzeichnis in einem bestehenden IIS3 oder IIS4, welcher neben den Bildern und Hilfetexten sehr viele ASP-Seiten enthält. Diese ASP-Seiten bauen eine Verbindung zum Exchange Server (auch mehrere) auf. Der Exchangeserver "sieht" einen normalen Mail-Client. Die ASP-Skripte formatieren die Rückgaben entsprechend um, dass diese Internetkonform sind (HTML, GIF-Bilder etc.). Neben den einfachen ASP-Seiten wird auch eine ISAPI-Filter-DLL (EXCHFILT.DLL) installiert. Diese nimmt bei der Verbindung des Browsers die Anfragen an, ermittelt unter anderem die Sprache des Browsers und leitet den Anwender dann auf die lokalisierte Seite um.

Der Browser auf der anderen Seite surfen unter Nutzung der allgemein verfügbaren Möglichkeiten und Ports (Javascript, Java etc.) einfach auf den Webserver.

OWA ist quasi ein Gateway (OSI-Schicht 7) zwischen den beiden sonst unvereinbaren Systemen Exchange Server und Browser und konvertiert die Informationen.

Installation

Die Installation ist recht einfach. Sie brauchen einen NT-Server mit einem installierten IIS3 mit ASP oder IIS4. Es ist dabei egal, ob dieser Server ihr PDC, BDC oder Member Server ist. Wir raten von der Installation des OWA auf einem Domain Controller ab, da die Gruppe der OWA-Benutzer das Recht "lokale Anmeldung" haben muss, und das will man als Administrator nicht unbedingt jedem User auf einem Domaincontroller zugestehen. Daher eignet sich ein Member Server vorzüglich. Ein "Standalone Server" ist nicht geeignet, genauso wenig wie eine NT Workstation oder gar Windows 95 oder Linux.

Der OWA Server kann sowohl auf dem Exchange Server als auch jedem anderen Server mit oben genannten Bedingungen installiert werden. Nachdem der Rechner ausgesucht ist, legen Sie einfach die Exchange CD ein und starten das Setup. Wählen Sie dann "Benutzerdefiniert", damit sie OWA alleine installieren oder nachinstallieren können. Mehr ist es eigentlich schon nicht. Es ist lohnend, auch hier das aktuelle Exchange Service Pack zu installieren, da diese einige Bugs behebt und natürlich Funktionen nachliefert. Was aber immer noch nicht geht, lesen sie weiter unten.

Achtung mit Select CDs. Sollten Sie kein SETUP.EXE finden, sondern eine SRVMAX.EXE oder SRVMIN.EXE dann kann es bei der Installation zu Problemen kommen. Kopieren Sie dann die CD auf eine Festplatte und benennen Sie SRVMAX.EXE nach SETUP.EXE um und starten dann das Setup. (Grüsse an Herrn Fellner nach österreich für diesen Tipp)

Daran sollten Sie denken: (Bitte lesen Sie auch weiter unten die Voraussetzungen für den Betrieb in der DMZ)

1. PFLICHT:

  • NT-Server in der Domäne
  • IIS3, 4, oder 5 
  • OWA installieren
    - Exchange Server CD rein
    - Setup aufrufen
    - Benutzerdefiniert auswählen
    - einfach nur OWA installieren (es ist fast so einfach) 
  • Servicepack Exchange installieren

2. Test von intern.

  • Zugriff auf http://servername/exchange. geht das schon ? 
    JA: OK
    NEIN: OWA Troubleshooter abarbeiten. (siehe Links am Ende dieses Dokument)

3. Zugriff von außen

(Siehe auch Firewall mit Exchange)

  • NT mit Iinternet Information Server (IIS) ans Internet (geht, mit Portfilter oder Firewall davor)
  • Firewall macht "reverse NAT" und setzt die IP Pakete für den Port um.
  • Firewall macht "reverse HTTP Proxy"
  • VPN von draußen nach "intern"

4. SICHERHEIT:

Konfiguration

Konfiguriert werden muss eigentlich gar nichts. Einfach loslegen unter http://name-des-servers/exchange und das war es schon.

  • Sicherung des Webservers
    OWA nutzt den IIS und daher ist zu prüfen, welche weitere Angebote dieser Webserver zur Verfügung stellt. Hier ist weniger mehr.
  • Authentifizierung
    Ach ja für die Nutzer von "Nicht IE"-Browsers. Per Default ist nur NTLM als Authentifizierung bei OWA frei geschaltet. Im Internet Dienst Manager sollte man vielleicht auch "Klarschrift" einschalten, damit sich auch andere Browser und Browser über Proxy Server erfolgreich anmelden können.
  • Sicherung per SSL
     Damit die Kennworte dann aber nicht offen übertragen werden (es sind schließlich die NT Anmeldekennworte) sollten Sie sich über SSL Gedanken machen)
  • Eigenes Design
    Sie können auch die ASP-Seiten nach ihrem Geschmack anpassen, bzw. die Startseite zumindest etwas umgestalten. Aber Vorsicht, da ein Service Pack wieder die original Dateien einsetzt und daher die Arbeit zu wiederholen ist

Konfiguriert wird dies aber alles im IIS-Admin, denn OWA ist nur ein virtuelles Verzeichnis des Webservers mit jede Menge ASP-Seiten und einer ISAPI-DLL.

Ports und Kommunikation

Outlook Web Access hat zwei Seiten der Kommunikation:

Vom Internet zu OWA

Auf der einen Seite erfolgt die Kommunikation mit dem Browser der Clients. Hierzu muss der OWA-Server über die Ports 80 (http) und eventuell auch 443 (SSL) erreichbar sein. Natürlich können sie diese Ports auch ändern und die Firewall entsprechend anpassen.

  • Port 80 HTTP für eingehenden Verkehr auf OWA
  • Port 443 HTTPS für eingehenden Verkehr auf OWA
  • Weitere Ports, wenn die Webseite nicht auf den Standardport laufen soll
  • Die Internetsysteme müssen den OWA-Server finden können (Stichwort DNS)

Von OWA zu  ...

Auf der anderen Seite kommuniziert der OWA-Server mit dem Exchange Server über die gleichen Ports, die auch ein Outlook Client nutzt. Aber es ist nicht nur der Exchange Server ist ein Partner, auch der Domain Controller und Namensdienste sind von Belang

  • Die Anwender müssen sich auf dem PC anmelden können. Demnach muss dieser PC die Anmeldung prüfen können (Zugriff auf Anmeldedienste)
  • Damit er überhaupt die DCs der Domäne findet, für die er OWA-Dienste bereitstellt, muss natürlich auch die Namensauflösung funktionieren. d.h. entweder WINS oder LMHOSTS-Einträge
  • Zuletzt muss er natürlich auch mit Exchange kommunizieren können. Dazu braucht er
    135 RPC Portmapper
    xxx MSExchange IS
    yyy MSExchange DS
    Leider sind die beiden Ports von Exchange von Hause aus dynamisch. Aber mit den entsprechenden Einstellungen in der Registrierung werden diese fixiert.

Die genauen Einstellungen zu den Ports finden man problemlos in der Microsoft TechNet. Links am Ende

Betrieb in einer DMZ

Nun wird niemand seinen Exchangeserver ins Internet stellen, sondern eher in eine DMZ. basierend auf den vorherigen Ausführungen können die Ports und Filter eingestellt werden. Aber wie installiert man OWA dort draußen, wo es doch ein Server in einer Domäne sein muss ? Es gibt auch hier zwei Möglichkeiten

  • OWA-Server ist Member Server der internen Domäne
    Demnach müssen von der DMZ nach intern die entsprechenden Ports freigegeben werden. Leider nutzen diese Ports ebenso die Dateizugriffe und andere Dienste. Demnach ist das vielleicht nicht die beste Funktion. Wenn der Rechner mal angegriffen wurde, ist ein Einbrecher schon halb in der Domäne drin. Dann wird ein Trojaner hinterlassen und gewartet, bis der Administrator sich anmeldet.
  • OWA-Server ist PDC einer eigenen Domäne und vertraut der internen Domain
    Dies ist die zweite Option. Es wird die gleiche Funktionalität erfüllt, aber der PC ist nicht Mitglied der internen Domäne  und hat dort auch kein Computerkonto. Entsprechend sind weniger Türen offen. Aber über den natürlich einseitigen Trust kann sich jeder von intern auf dem OWA anmelden und arbeiten.

Genau genommen sind die unterschiede marginal, aber im Einzelfall sicher zu beachten, damit die firmeneigene Sicherheitsrichtlinie umgesetzt werden kann.

Betrieb mit mehreren Domains

Mit dem Wissen, das sie nun haben, sollten sie alleine erkennen können, was einzustellen, ist, dass OWA auch mit mehreren Exchange Servern in mehreren Domains zurechtkommt. Es "geht" einfach, wenn folgendes erfüllt ist

  • Die Namensauflösung ist korrekt installiert (WINS oder LMHOSTS, DNS alleine reicht nicht, weil NT4 per DNS keine Domaincontroller finden kann)
  • OWA-Server findet mindestens den PDC der jeweiligen Domäne und kann ihn auch zur Authentifizierung der Anwender nutzen
  • OWA vertraut der Domäne, bzw. die Domäne, der er zugehörig ist, vertraut der anderen Domäne
  • Die User der anderen Domäne haben das Recht "Lokale Anmeldung" auf dem OWA-Server
  • OWA kann zu jedem der Exchangeserver eine Verbindung aufnehmen (Ports auf allen Server fixiert ?, Regeln in der Firewall offen)

Dann steht dem zentralen OWA-Server nichts mehr im Wege-

OWA für mehrere Server

Ein OWA-Server viele Exchange Server bedienen, auch wenn diese in anderen Sites stehen. Allerdings nicht, wenn Sie in einer anderen Organisation stehen. Damit ein OWA-Server aber verschiedene Server in einer Organisation bedienen kann muss man immer die Voraussetzungen betrachten, die beim Betrieb von OWA in mehreren Domains gelten. Erst dann kann es weiter gehen.

OWA liest dazu über LDAP und RPC von seinem primären Server (Er selbst oder der bei der Installation angegeben wurde) die Liste der User und findet den Anwender in der Globalen Adressliste (GAL). Dieser muss natürlich schon auf diesen Server repliziert und sichtbar sein. Weiterhin muss er "eindeutig" sein. Es gibt nur wenige Dinge, die bei Exchange "eindeutig" sind. Zwar können wir in der Eingabemaske den Alias des Benutzers verwenden, aber dieser ist nicht immer eindeutig über die gesamte Organisation hinweg. Im Zweifel sollten Sie daher einfach ihre komplette SMTP-Adresse eingeben, dann ist die Eindeutigkeit sichergestellt.

Nun stellt sich aber für die Firma die Frage, ob ich einen OWA-Server für meine Exchange Organisation zentral installieren soll, oder jede Site ihren eigenen OWA-Server installieren muss. Bei dieser Entscheidung spielen Performance, Sicherheits- und Netzlastaspekte eine große Rolle. Welche Seite des OWA macht mehr Last ? Der Browser zum Server oder der OWA-Server zum Exchange ?. OWA auf dem IIS ist "wie ein Outlook" zu betrachten. Zwei Szenarien sind denkbar:

Browser ---- HTTP ---- OWA-Server1 ----- RPC ---- Exchange1
                              !--------- RPC ---- Exchange2
Browser ---- HTTP ---- OWA-Server1 ----- RPC ---- Exchange1
             HTTP ---- OWA-Server2 ----- RPC ---- Exchange2

Ein OWA kann theoretisch alle Benutzer  bedienen, deren Postfach in der gleichen Exchange Organisation ist, solange er über LAN oder WAN auf den anderen Exchangeserver zugreifen kann. Aber folgende Punkte wollen bedacht sein

  • Alle Exchange Server müssen sich finden und erreichen lassen 
  • Der Anwender sich auf dem OWA "lokal anmelden" können.
  • Nutze ich nur einen OWA-Server, dann muss ich einmal den Zugang über die Firewall einrichten und kontrollieren.
  • Dafür hat der eine Server durch mehrere Benutzer mehr "zu tun.
  • Umgekehrt kann ich aber zentral leichter einen Pool von Servern aufstellen, um die Performance zu skalieren und eine höhere Ausfallsicherheit zu realisieren
  • Ich kann zentral Verwalten, Ein OWA-Zugang in einer Niederlassung könnte auch zusätzliche Informationen enthalten
  • Ein Corporate Identity und die Verwaltung von Sicherheit per SSL ist zentral leichter zu erzwingen.
  • Benutzer, die umziehen brauchen beim zentralen Server nichts umzustellen
  • Und das sind nur einige Argumente

Sie merken schon, dass ich eher für  den zentralen Server argumentiere. Aus Sicht der Netzwerklast gibt sich OWA nichts, ob nun RPC oder HTTP über das interne WAN gehen. Allerdings ist RPC innerhalb schwerer zu filtern, wenn man nicht dir richtige Firewall einsetzt.

Anpassen von OWA

Der Outlook Web Zugriff besteht bei Exchange 5.5 unter der Oberfläche aus ASP-Seiten. Mittels Active Server Pages werden die Informationen aus Exchange geholt, aufbereitet und dem Browser zugeleitet. Wenn Sie daher die Form oder Farben anpassen wollen, müssen Sie die ASP-Seiten entsprechend Anpassen. Sie können dies z.B. per Frontpage oder jedem anderen HTML-Editor erreichen. Allerdings sollten Sie immer nur eine Seite ändern und dann die Funktion testen und zudem eine Sicherung des Originals haben. Einfacher ist hierbei die Veränderung der Grafiken oder die Gestaltung einer eigenen Eingangsseite.

Bei der Installation eines Service Packs werden aber alle Änderungen nach WEBDATA.OLD verschoben und die ASP-Seiten durch die Versionen des Service Packs ersetzt. Achten Sie daher darauf, die Änderungen entsprechend zu dokumentieren, damit Sie diese wieder nachführen können.

Der HTTP-Zugriff bei Exchange 2000 wird nicht mehr über ASP-Seiten bereitgestellt, sondern über eine ISAPI-Filter-DLL. Hier ist als einfachste Veränderung z.B.: das Logo unter C:\Programme\Exchsrvr\exchweb\img\logo-ie5.gif anzupassen. Alles weitere bedeutet einen höheren Programmieraufwand. Auf der anderen Seite können Sie aber gezielt Teile des Informationsangebots in eigene Webseite (z.B. per Frames) einbinden. Schließlich ist jede Ansicht und jedes Objekt direkt per URL ansprechbar

Mehrsprachigkeit

Outlook Webzugriff mit Exchange 5.5 ist mehrsprachig ausführbar. Dazu sind einfach die entsprechenden Sprachen zu installieren. Wenn Sie einen deutschen OWA installieren, erhalten Sie automatisch die Verzeichnisse GER und uS. Die EXCHFILT.DLL im Webserver erkennt anhand der Sprache des Clients (der Browser), in welches virtuelle Verzeichnis der Verweis erfolgt.

Sicherer Zugriff per SSL

Tja das ist keine Frage des Outlook Web Access, sondern mehr einer Frage des eingesetzten Webservers. für den IIS3 als auch den IIS4 kann man bei einer Zertifizierungsstelle ein Serverzertifikat anfordern (gegen $$$) und das dann in deinem IIS einstellen. danach kannst du das "virtuelle Verzeichnis" "/EXCHANGE" als "SSL" aktivieren. Und schon geht es "sicher" weiter. Nun halt die Frage "Woher" bekommt man ein Zertifikat. Nun ja eben bei einer entsprechenden Zertifizierungsstelle.

Schau einfach in deinem Browser, wen es da so gibt. Bei mir ist das z.B.

Ach ja dann gibt es da natürlich noch Net at Work. Wir haben uns auch unsere eigene CA installiert. Allein für eine verschlüsselte SSL-Verbindung müssen Sie kein SSL-Zertifikat kaufen. Sie können sich mit dem Zertifikatsserver von Windows 2000 oder dem NT4 Option Pack natürlich auch selbst ein Zertifikat ausstellen. Dann werden Sie zwar auf den meisten Browsern der Welt eine Warnung erhalten, dass das Zertifikat von einer unbekannten CA ausgestellt worden sei, aber verschlüsselt ist die Verbindung dann trotzdem.

Siehe Internet Eigenschaften " Inhalt" Zertifikate - Agenturen. Bei denen kann man sich dann die Zertifikate "Kaufen" und einspielen.

Genau genommen musst du auf deinem IIS einen Key erstellen (Wird erstellt aus der URL, Land, Ort, Person, Firmenname) und den bei Zertifizierungsstelle mit deren Key "signiert". diesen codierten Key bekommst du zurück zum einspielen.

Nun bekommt jeder Browser diesen Key zugesandt, den er mit dem Public Key der Zertifikatsstelle (die mit dem Browser meist mitkommen, die du aber sonst von der Webseite laden und installieren kannst) decodieren kann und dann eben prüft, ob da drin die gleiche Home-URL steht, wie die des Browsers. Damit verhindert man also auch dass jemand deine Webseite "umleitet".

Mit dem gleiche Key (auch dein Browser erzeugt einen bzw. hat einen) wird dann auch die Datenübertragung gesichert Das genaue Verfahren ist natürlich etwas aufwendiger. So ist meine Beschreibung weder vollständig noch 100% richtig.

Aber das Vorgehen ist klar.

  • Key mit dem Schlüsselmanager der IIS erstellen.
  • Key zertifizieren lassen (Kostenpflichtig je nach Wahl der CA)
  • Key einspielen
  • Verzeichnis /Exchange auf "SSL erzwingen" setzen.
    Bitte aber die Fehlermeldung bei "nicht SSL"-Zugriff abfangen und die Anwender auf die SSL-Seite umleiten.

Eine How-To-Anleitung für SSL finden Sie auf:

Es gibt auch in Deutschland einige Zertifikate. Gehe einfach mal auf http://www.ccc.de Die haben ihre ganze Seite (nach einem Klau) nun zertifiziert und dort ist es auch erklärt. Siehe http://hades.pizzaservice.de/crypto/ssl.html Wenn ich auch in der genialen TechNet nach SSL suche, dann kommen 380 Vorkommen. z.B. Q171084 How to install a Certificate.

Was alles nicht geht

Tja und das ist schon traurig aber nicht zu ändern. Jedes Service Pack verkleinert die Liste der fehlenden Funktionen aber es bleibt noch einiges zu tun. (Stand Exchange 5.5. SP4)

  • Kein Einblick in globale Kontakte
  • Keine Nutzung der "Notizen"
  • keine Nutzung der "Aufgaben"
  • .... Liste wird fortgesetzt

Wie man sieht bleibt noch viel Platz für alternative Wege wie diese unter Konzepte beschrieben werden.

OWA und Outlook

Wenn Sie planen, Outlook und OWA auf einem Server zu installieren, dann sollten Sie wissen, dass die Installation von Outlook 2000 (und höher) und Exchange Server 5.5 (auch nur OWA) auf dem selben System ist eine nicht von Microsoft unterstützte Konfiguration darstellt. Problemtisch ist hierbei, dass beide eine verschiedene Versionen des MAPI Subsystem mitliefern.

"Exchange installs its MAPI subsystem under the \Winnt\System32 folder.
Starting with Outlook 2000 MAPI subsystem moves to the \Program Files\Common
Files\System\Mapi\1033\NT folder. Normally, Outlook installs a "stub"
version of MAPI into the \Winnt\System32 folder, which routes MAPI calls to
Outlook's implementation. If Exchange is running when Outlook is installed,
the Mapi32.dll file is still loaded, and is not replaced by the stub DLL.
This breaks Outlook's Mapi32 stub mechanism and leaves two different
versions of MAPI on the system."
Quelle nicht mehr ermittelbar

  • Q252653 Description of Fixmapi.exe Tool Included w/ Internet Explorer 5
  • Q228457 Description of Fixmapi.exe Tool Included w/ Internet Explorer 5
  • Q288836 INFO: Supported MAPI Configurations

Normalerweise ist dies aber kein Problem, da auf einem OWA-Server mit IIS und Internetzugang  in der Regel kein Outlook benötigt wird.

Fehlersuche

Fehlersuche ist knifflig aber möglich.

  • Melden Sie sich auf dem OWA-Server interaktiv mit dem User an, der Probleme hat. 
    Geht es nicht, dann Kennwort prüfen, Eventlog prüfen, Vertrauensstellung prüfen, Haben sie dem User das Recht "Lokale Anmeldung" im Usermanager gegeben ?
  • Nun sind sie angemeldet. Konfigurieren Sie ein Outlookprofil für diesen Benutzer unter seinem Namen mit dem Server, den OWA bei der Installation erfragt hat und drücken sie Überprüfen. Wird der Name aufgelöst und der richtige Server eingetragen ?
    Wenn nicht, dann Schreibweise prüfen, Tippfehler. Gibt es gleichnamige Benutzer, so dass der eingegebene Name nicht eindeutig ist (Tipp: SMTP-Adresse bei OWA als Alias eingeben)
  • Starten sie Outlook. Kommen Sie auf das Postfach ?
    Wenn nein, dann Regeln der Firewall, Filter, Bindungen, Leitwege, Routing etc. Prüfen. Eventlog auf dem Exchange Server hoch setzen und schauen. Solange Outlook auf dem OWA-Server nicht funktioniert, kann auch OWA nicht funktionieren
  • Gehen Sie auf http://servername. Kommt die Standardseite ?
    JA: OK weiter
    Nein: Bringen die zuerst den IIS in Ordnung. Dann geht es hier weiter
  • Gehe auf http://server/exchange, Kommt die OWA Anmeldung
    JA: OK nächster Punkt
    NEIN: versuche http://servername/exchange/ger/logon.asp
    Kommt nun die OWA-Maske ?
    JA, dann ist die ISAPI-DLL "exchfilt.dll" nicht mehr aktiv
    NEIN: dann ist OWA nicht richtig installiert, Virtuelles Verzeichnis falsch oder du bis auf dem falschen virtuellen Webserver
  • Und nun OWA. Geht es immer noch nicht ?
    Dann brauchen wir schon die Fehlermeldung. Einfach mit dieser Meldung in der Newsgroup fragen. Übrigens liefert Outlook Web Access auch eine Fehlerbeschreibung mit. Sie finden sie auf ihrem Server einfach unter http://servername/exchange/tshoot.asp

Weitere Schritte können Sie selbst ableiten, wenn Sie sich die Funktion des Exchange 5.5 OWA aus "Q263236 XWEB: Exchange Server 5.5 Outlook Web Access Logon Process" erarbeiten.

Sicherheit und OWA

Exchange 5.5. OWA ist eine Sammlung von ASP-Seiten, welche auf dem Webserver ausgeführt werden und Parameter über URLs erhalten. Es ist möglich und Realität, dass Programme mit Fehlern behaftet sind und damit der OWA-Zugriff missbraucht werden kann. Kontrollieren Sie daher regelmäßig die Sicherheitsseiten von Microsoft unter www.Microsoft.com/security. Im Dezember 2001 war zumindest der Artikel unter http://www.Microsoft.com/technet/security/bulletin/MS01-057.asp relevant.

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.

Weitere Links

In der TechNet und Knowledgebase kommen sie mit dem Suchbegriff "XWEB" die relevanten Artikel zu sehen.

  • Outlook OWA Troubleshooting Guide
    Arbeiten Sie diese Seite auf jeden Fall komplett durch 
  • http://www.Microsoft.com/exchange/outlook/default.htm
    Auf dieser Seite sind verschiedenste White Paper bezüglich OWA vorhanden.
  • Exchange Server 5.5 Outlook Web Access (OWA) Language Packs
    Damit sie iihren Server mit weiteren Sprachen ausstatten können
  • MSXFAQ - OWA mit ISA und SSL
  • Q148732XADM: Setting TCP/IP Port Numbers für Internet Firewalls
  • Q155831XADM: Setting TCP/IP Ports für Exchange and Outlook Client Connections Through a Firewall
  • Q165661 XWEB: Error Message: Failed to Get Inbox
  • Q165987 XWEB: Error Message: Failed to Get Inbox
  • Q230273 XWEB:OWA Creates English Special Folders (Contacts, Calendar...) During First Logon"
  • Q166994 XWEB: Spaces in Alias Name Cause "Failed to get Inbox"
  • Q167003 XWEB: Troubleshooting Active Server Components 
  • Q167260 XCLN: How to use RPCPing to Test RPC Communication
  • Q171084 How to install a Certificate
  • Q173451 XWEB: Err Msg: Failed to get Inbox, using OWA
  • Q173470: XCLN: Troubleshooting "Failed to get Inbox" Error Message
  • Q173676 Client Cannot Resolve MX Record via Microsoft DNS Server
  • Q174352 XWEB: How to Improve Error Messages für T'shooting Web Access
  • Q175122 XWEB: Error Msg: Failed to Get Inbox in Outlook Web Access
  • Q175698 MS Exchange FAQs from Support Online
  • Q175892 XWEB: Permissions Required für Outlook Web Access
  • Q178761: XWEB: Attachments ProdUCE JavaScript Errors in Browser
  • Q189654 XWEB: "Failed To Get Inbox" Error May Occur If Name Is Ambiguous
  • Q190433 XWEB: Err Msg: Current Password Is About to Expire in 0 Days
  • Q186863 XWEB: unable to Change Password using OWA
  • Q187650 Error: 'Server Returned Invalid or unrecognized Response'
  • Q198509 XWEB: 'Unable to get your inbox' using OWA via Proxy Server
  • Q207655 XWEB: Setting up Web Publishing and OWA Access Through a Proxy
  • Q228991 How to Create and Install an SSL Certificate in Internet Information Server 4.0
  • Q234022 XCLN: Configuring Exchange OWA to use SSL [Q234022]
  • Q234805 XWEB: How to Install OWA and IIS on a Stand-Alone Server
  • Q236811XWEB How to Set up OWA für Specific Users  
  • Q239569 XWEB: Requirements für Outlook Web Access
  • Q246203Configuring OWA Outside the Default Web Site
  • Q246493 XWEB: How to Remove the Change Password Button in OWA
  • Q248081 XWEB: Suddenly and Permanently unable to Reach Inbox using OWA
  • Q248486 XCCC: Mailbox Access Across Domains Is Denied Through OWA
  • Q249431 XWEB: Client-based Rules Are Not Available in Outlook Web Access
  • Q251445 XWEB: Anonymous User with Full Permission Cannot Delete Post
  • Q255457 XCCC Time Zone on OWA Client Does Not Match the Time on the Local Computer
  • Q257591 Description of the Secure Sockets Layer (SSL) Handshake
  • Q259240 XWEB: Configure OWA to Connect to Exchange Through a Firewall
  • Q250667 XWEB: Mailbox access through OWA is denied when Proxy server is
  • Q261953 XWEB: How to Enable OWA on Two Independent Web Sites under IIS
  • Q263236 XWEB Exchange Server 5.5 Outlook Web Access Logon Process
  • Q265847 Err Msg: The Page Cannot Be Displayed . . .
  • Q267568 XWEB: Old Password Still Works After You Change It Through OWA
  • Q268419 HOWTO: Enable Password Change Functionality für OWA
  • Q262181 XWEB Virtual Internet Information Server Directories used By Outlook Web Access
  • Q263236 XWEB: Exchange Server 5.5 Outlook Web Access Logon Process
  • Q274397XCCC OWA Does Not Support Integrated Windows Authentication on Front-End Servers
  • Q288119 XWEB: How to Disable the Multimedia Button in OWA
  • Q297121 XWEB: How to Hide the Change Password Button on the Outlook Web Access Options Page
  • Q298805 HOW TO: Enable SSL für All Customers Who Interact with Your Web Site
  • Q299525 HOWTO: Set up SSL using IIS 5.0 and Certificate Server 2.0
  • Q299875 HOW TO: Implement SSL on a Windows 2000 IIS 5.0 Computer
  • Q307638 HOWTO: Change the Icon Displayed für an Item in OWA
  • Q309508 XCCC: IIS Lockdown and URLscan Configurations in an Exchange Environment
  • Q301428 Troubleshooting Outlook Web Access from an IIS Perspective
  • Q309677 XADM: Known Issues and Fine Turning When You use the IIS Lockdown Wizard in an Exchange 2000 Environment
  • http://www.iisfaq.com/SSL OWA und SSL
  • Planning and Deploying MS Outlook Web Access
  • MS Outlook Web Access Performance and Extensibility
  • Microsoft Outlook Web Access HOWTO (Simpler-Webb)
  • Brian Zoromski's FAQ für Outlook Web Access
  • Steve Luzynski's FAQ für Outlook Web Access
  • Outlook Web Access Security (SWYNK.com)
  • Outlook Web Access Permissions (SWYNK.com)
  • A look at Exchange 5.5's Outlook Web Access (Exploring Windows NT)
  • Customize Your OWA Logon/Logoff Screens (Exchange Administrator Newsletter)
  • SSL's Benefits on OWA (Exchange Administrator Newsletter)
  • Happy 10th birthday, Outlook Web Access!
    http://blogs.technet.com/b/exchange/archive/2007/06/13/441461.aspx