36
Exchange 2010 OWA über externe IP-Adresse ansprechen
Hallo liebe Mitglieder,
ich möchte auf einem W2008R2 mit Exchange 2010 den Zugriff auf das OWA über eine externe IP-Adresse ermöglichen.
Der Stand ist:
OWA ist für Port 443 freigeschaltet.
Auf dem Router wird mit einer Portweiterleitung und NAT der externe Port auf den internen 443 weiter gereicht.
Zum Test habe ich die externe Adresse derzeit per NAT ebenfalls auf die interne Routeradresse umsetzen lassen.
Somit kommen die Requests Adresstechnsich vom internen Routerinterface.
Ein grober Blick auf Wireshark bestätigt mir, dass das auch.
Intern kann ich sowohl über den voll qualifizierten Namen als auch über die Server-IP Adresse auf das OWA zugreifen.
Von extern komme ich auch auf die Standard Default Seite mit dem hübschen Willkommensgruß.
Der Datenfluß scheint also soweit zu stimmen.
Nur beim Zugriff auf https://<externe-ip>:<externerPort>/owa kommt nach einiger Wartezeit "Die Seite kann nicht angezeigt werden"
Ein neues selbstsigniertes Zertifikat ist wie hier beschrieben "http://notes.ponderworthy.com/create-new-self-signed-certificate-for-exchange-2010" erstellt, um die externe Adresse des Routers erweitert und zugeordnet.
Das OWA-Verzeichnis ist inzwischen auch schon einmal neu angelegt worden.
Kann mir jemand auf die Sprünge helfen wie ich dem Problem her werden kann?
Die wirklich zahlreichen Beiträge, die zu diesem Thema zu finden sind, haben mich auch nach zwei Tagen Probieren nicht weiter gebracht.
Evtl. habe ich hier ja ein grundsätzliches Verständnisproblem zum Verhalten des IIS bzgl. /OWA ?
Danke und Gruß
Uwe
ich möchte auf einem W2008R2 mit Exchange 2010 den Zugriff auf das OWA über eine externe IP-Adresse ermöglichen.
Der Stand ist:
OWA ist für Port 443 freigeschaltet.
Auf dem Router wird mit einer Portweiterleitung und NAT der externe Port auf den internen 443 weiter gereicht.
Zum Test habe ich die externe Adresse derzeit per NAT ebenfalls auf die interne Routeradresse umsetzen lassen.
Somit kommen die Requests Adresstechnsich vom internen Routerinterface.
Ein grober Blick auf Wireshark bestätigt mir, dass das auch.
Intern kann ich sowohl über den voll qualifizierten Namen als auch über die Server-IP Adresse auf das OWA zugreifen.
Von extern komme ich auch auf die Standard Default Seite mit dem hübschen Willkommensgruß.
Der Datenfluß scheint also soweit zu stimmen.
Nur beim Zugriff auf https://<externe-ip>:<externerPort>/owa kommt nach einiger Wartezeit "Die Seite kann nicht angezeigt werden"
Ein neues selbstsigniertes Zertifikat ist wie hier beschrieben "http://notes.ponderworthy.com/create-new-self-signed-certificate-for-exchange-2010" erstellt, um die externe Adresse des Routers erweitert und zugeordnet.
Das OWA-Verzeichnis ist inzwischen auch schon einmal neu angelegt worden.
Kann mir jemand auf die Sprünge helfen wie ich dem Problem her werden kann?
Die wirklich zahlreichen Beiträge, die zu diesem Thema zu finden sind, haben mich auch nach zwei Tagen Probieren nicht weiter gebracht.
Evtl. habe ich hier ja ein grundsätzliches Verständnisproblem zum Verhalten des IIS bzgl. /OWA ?
Danke und Gruß
Uwe
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 255284
Url: https://administrator.de/forum/exchange-2010-owa-ueber-externe-ip-adresse-ansprechen-255284.html
Ausgedruckt am: 21.04.2025 um 12:04 Uhr
36 Kommentare
Neuester Kommentar
Hi,
Hast du es denn auch im IIS der Default Web Site in den 443 Bindung zu geordnet?
VG
Criemo
Hast du es denn auch im IIS der Default Web Site in den 443 Bindung zu geordnet?
VG
Criemo
Hallo Criemo,
danke für den Hinweis.
Wenn du damit das Zertifikat meinst, ja das ist zugeordnet.
Gruß
Uwe
danke für den Hinweis.
Wenn du damit das Zertifikat meinst, ja das ist zugeordnet.
Gruß
Uwe
Hallo Openmind,
Schon mal einen Connectivity test gemacht?
einmal in den Exchange Tools
und einmal auf der PS?
VG Criemo
Schon mal einen Connectivity test gemacht?
einmal in den Exchange Tools
und einmal auf der PS?
Test-OwaConnectivity -URL:https://domain.local/owa -MailboxCredential:(get-credential domain\user)VG Criemo
Hallo Criemo,
danke für deine Hilfe.
in der PS bekomme ich in der Tabelle die URL mit Result Erfolgreich angegeben.
Meinst du mit Tools den RemoteVerbindungstest, der auf die MS Website https://testconnectivity.microsoft.com verweist?
Den kann ich leider nicht ausführen, da das Formular die URL nicht als gültig akzeptiert, warum kann ich nicht sagen.
Ich gebe dort "https://externe-ip:externer-port/owa" an. Aber auch willkürliche URL's werden nicht akzeptiert.
Grundsätzlich wird der interne Test vermutlich nichts anderes bringen kann als OK, da dies ja wie oben beschrieben geht
und der externe Zugriff auf die Startseite geht ja auch.
Gruß Uwe
danke für deine Hilfe.
in der PS bekomme ich in der Tabelle die URL mit Result Erfolgreich angegeben.
Meinst du mit Tools den RemoteVerbindungstest, der auf die MS Website https://testconnectivity.microsoft.com verweist?
Den kann ich leider nicht ausführen, da das Formular die URL nicht als gültig akzeptiert, warum kann ich nicht sagen.
Ich gebe dort "https://externe-ip:externer-port/owa" an. Aber auch willkürliche URL's werden nicht akzeptiert.
Grundsätzlich wird der interne Test vermutlich nichts anderes bringen kann als OK, da dies ja wie oben beschrieben geht
und der externe Zugriff auf die Startseite geht ja auch.
Gruß Uwe
Hi,
okay also irgendwie müssen wir ja dahinter kommen was nun los ist
kannste es mal hiermit Probieren:
http://mxtoolbox.com/
domain eingeben und anschließend auf Find Problems gehen?
VG
Criemo
okay also irgendwie müssen wir ja dahinter kommen was nun los ist
kannste es mal hiermit Probieren:
http://mxtoolbox.com/
domain eingeben und anschließend auf Find Problems gehen?
VG
Criemo
Hallo Criemo,
gerne, nur verstehe ich nicht so ganz wie das gehen soll, weil...
extern habe ich einen MX Eintrag der auf den eMail-Server des Providers verweist (Smarthost).
Ich gehe auf den Exchange im LAN aber über die dedizierte externe IP Adresse des Routers.
Intern ist im internen DNS ein MX Eintrag auf den Exchangeserver im LAN mit der lokalen Domäne vorhanden.
Das mxtoolbox.com versucht den MX Eintrag im Internet zu finden, dort findet es zu der externen Domäne auch die Einträge, nur haben diese ja nichts mit dem Exchangeserver zu tun.
Oder verstehe ich dich da falsch?
Gruß Uwe
gerne, nur verstehe ich nicht so ganz wie das gehen soll, weil...
extern habe ich einen MX Eintrag der auf den eMail-Server des Providers verweist (Smarthost).
Ich gehe auf den Exchange im LAN aber über die dedizierte externe IP Adresse des Routers.
Intern ist im internen DNS ein MX Eintrag auf den Exchangeserver im LAN mit der lokalen Domäne vorhanden.
Das mxtoolbox.com versucht den MX Eintrag im Internet zu finden, dort findet es zu der externen Domäne auch die Einträge, nur haben diese ja nichts mit dem Exchangeserver zu tun.
Oder verstehe ich dich da falsch?
Gruß Uwe
extern habe ich einen MX Eintrag der auf den eMail-Server des Providers verweist (Smarthost).
Intern ist im internen DNS ein MX Eintrag auf den Exchangeserver im LAN mit der lokalen Domäne vorhanden.
Intern ist im internen DNS ein MX Eintrag auf den Exchangeserver im LAN mit der lokalen Domäne vorhanden.
????? Bist Du sicher, das Du weisst, wovon Du schreibst
??LG, Thomas
Hallo keine-Ahnung,
danke, sehr hilfreich.
Gruß Uwe
danke, sehr hilfreich.
Gruß Uwe
es geht nicht um ds was der Exchange ausspuckt sondern der WebServer also der IIS
hast du es mal mit deinem Handy versucht? komplett außerhalb des internen netzes?
hast du es mal mit deinem Handy versucht? komplett außerhalb des internen netzes?
Hallo Criemo,
wie ich oben geschrieben habe, vermute ich ja auch dort das Problem
und ja ich versuche den externen Zugriff die ganze Zeit von außerhalb.
Von dort komme ich mit "https://externe-ip:externer-port/" auf die Willkommens-Startseite des IIS.
Nur halt nicht auf "https://externe-ip:externer-port//owa".
LG Uwe
wie ich oben geschrieben habe, vermute ich ja auch dort das Problem
und ja ich versuche den externen Zugriff die ganze Zeit von außerhalb.
Von dort komme ich mit "https://externe-ip:externer-port/" auf die Willkommens-Startseite des IIS.
Nur halt nicht auf "https://externe-ip:externer-port//owa".
LG Uwe
Sorry ist vielleicht ne blöde Frage, aber hast du die externe Adresse auch in der Exchange Console hinterlegt?
Hast du die IIs Seiten neu generieren lassen?
Moin
Prinzipiell brauchst du den Port nicht mit anzugeben, da es sich ja um den Standard-Port für HTTPS-Anfragen handelt (443).
Vielleicht ist es nur ein Schreibfehler deinerseits (2 x / vor OWA), aber probiere doch mal https://externe-IP/owa
Ansonsten solltest du den Fehler im IIS suchen, wie @Criemo es schon schrieb.
Zitat von @openmind:
Von dort komme ich mit "https://externe-ip:externer-port/" auf die Willkommens-Startseite des IIS.
Nur halt nicht auf "https://externe-ip:externer-port//owa".
Von dort komme ich mit "https://externe-ip:externer-port/" auf die Willkommens-Startseite des IIS.
Nur halt nicht auf "https://externe-ip:externer-port//owa".
Prinzipiell brauchst du den Port nicht mit anzugeben, da es sich ja um den Standard-Port für HTTPS-Anfragen handelt (443).
Vielleicht ist es nur ein Schreibfehler deinerseits (2 x / vor OWA), aber probiere doch mal https://externe-IP/owa
Ansonsten solltest du den Fehler im IIS suchen, wie @Criemo es schon schrieb.
@goscho
So wie ich es oben verstanden habe benutzt er von außen einen anderen Port der dann auf 443 geforwarded wird!
VG Criemo
So wie ich es oben verstanden habe benutzt er von außen einen anderen Port der dann auf 443 geforwarded wird!
VG Criemo
Überprüfe mal ob bei
Alles richtig angezeigt wird?
Ist das Zertifikat wirklich auf der entsprechenden Bindung hinterlegt?
Get-OwaVirtualDirectory -Identity "Server\owa (default Web site)" |fl Alles richtig angezeigt wird?
Ist das Zertifikat wirklich auf der entsprechenden Bindung hinterlegt?
Hallo Criemo,
nochmals danke für deine Hilfe.
Zu den letzten Kommentaren:
Ja ist richtig, ich benutze von außen einen anderen Port, der dann auf intern 443 umgesetzt wird; daher die Angabe in der URL.
Get-OwaVirtualDirectory gibt mir drei Spalten aus:
Name: owa (Default Web Site)
Server: <der richtige Servername>
OwaVersion: Exchange2010
Zur Frage ob ich die Die IIS Seite neu generieren lassen habe:
Ich habe den Hinweis in den Foren gefunden gehabt, dass das Virtuelle Directory (dass war glaube nach einem Patch auf einem SBS, oder so) gecrasht sein kann.
Ich habe dieses daraufhin neu erstellt, hatte aber keine Änderung gebracht.
Letztendlich funktioniert es intern ja auch.
Die Bindung des Zertifikates ist auf https hinterlegt.
Zu deiner Frage: "...aber hast du die externe Adresse auch in der Exchange Console hinterlegt?"
Was meinst du bitte damit genauer ?
Was ich nicht verifiziert habe, ist die Aussage, das zu OWA nur der Port 443 benötigt wird, wenn dem nicht so ist, wäre das eine plausible Erklärung warum der IIS die OWA Seite nicht ausliefern kann. Aber dann müsste es doch eigentlich auch dokumentiert sein.
Gruß
Uwe
nochmals danke für deine Hilfe.
Zu den letzten Kommentaren:
Ja ist richtig, ich benutze von außen einen anderen Port, der dann auf intern 443 umgesetzt wird; daher die Angabe in der URL.
Get-OwaVirtualDirectory gibt mir drei Spalten aus:
Name: owa (Default Web Site)
Server: <der richtige Servername>
OwaVersion: Exchange2010
Zur Frage ob ich die Die IIS Seite neu generieren lassen habe:
Ich habe den Hinweis in den Foren gefunden gehabt, dass das Virtuelle Directory (dass war glaube nach einem Patch auf einem SBS, oder so) gecrasht sein kann.
Ich habe dieses daraufhin neu erstellt, hatte aber keine Änderung gebracht.
Letztendlich funktioniert es intern ja auch.
Die Bindung des Zertifikates ist auf https hinterlegt.
Zu deiner Frage: "...aber hast du die externe Adresse auch in der Exchange Console hinterlegt?"
Was meinst du bitte damit genauer ?
Was ich nicht verifiziert habe, ist die Aussage, das zu OWA nur der Port 443 benötigt wird, wenn dem nicht so ist, wäre das eine plausible Erklärung warum der IIS die OWA Seite nicht ausliefern kann. Aber dann müsste es doch eigentlich auch dokumentiert sein.
Gruß
Uwe
Hallo Uwe,
eigentlich meinte ich das so sorry.
schaumal bei internal und External Url ob dort die richtige URL hinterlegt ist!
OWA benutzt nur 443. Keine Sorge
VG
Criemo
Get-OwaVirtualDirectory -Identity "Server\owa (default Web site)" |fl eigentlich meinte ich das so sorry.
schaumal bei internal und External Url ob dort die richtige URL hinterlegt ist!
OWA benutzt nur 443. Keine Sorge
VG
Criemo
Hallo Criemo,
bei InternalURL steht: https://<Servername>.<interneDomäne>.local/owa
bei ExternalURL steht: https://<exterenIP>/owa
So richtig?
Gruß
Uwe
bei InternalURL steht: https://<Servername>.<interneDomäne>.local/owa
bei ExternalURL steht: https://<exterenIP>/owa
So richtig?
Gruß
Uwe
ja eigentlich schon.
wie sieht es denn mit dem Portforwarding aus und deiner NAT regel. weil ich glaube nicht mehr dass es am IIs liegt ich vermute mittlerweile dass es an deiner Firewalleinstellung liegt. Könntest du das nochmal checken und testen. teste mal wenn du kein Forwarding machst sondern denn Port 443 einfach nach außen legst?
VG
Criemo
wie sieht es denn mit dem Portforwarding aus und deiner NAT regel. weil ich glaube nicht mehr dass es am IIs liegt ich vermute mittlerweile dass es an deiner Firewalleinstellung liegt. Könntest du das nochmal checken und testen. teste mal wenn du kein Forwarding machst sondern denn Port 443 einfach nach außen legst?
VG
Criemo
Hallo Criemo,
echt Klasse dass du bei der Stange bleibst und mir helfen willst.
Also ich bin da nochmal gedanklich nüchtern rangegangen und habe die Einstellungen geprüft.
Ich sehe im Wireshark einen SSL Vereinbarung und wie dann Daten ausgetauscht werden.
Da verschlüsselt kann ich ja leider nicht reingucken, aber wie gesagt direkt auf die DefaultWebSite bekomme ich die Standard WillkommenSeite.
Wenn ich mich mal von außen durch die installierten virtuellen Verzeichnisse so durchteste, bekomme ich z.B. bei /PowerShell ein Forbidden usw..
Zum weiteren Test habe ich jetzt einfach mal ein virtuelles /Test Verzeichnis im physikalischen wwwroot-Pfad mit einer index.html angelegt, da kann ich dann sofort drauf zugreifen.
Daraufhin bin ich mal in das physikalische Verzeichnis C:\Programme\Microsoft Exch....\V14\ClientAccess\owa gegangen und habe mal dort alles weggesichert und auch eine index.html angelegt und siehe da
... kein Zugriff !
Da passt doch was mit den Zugriffsrechten nicht, oder?
Habe nur leider kein Referenzsystem zum Vergleich übrig.
VG
Uwe
echt Klasse dass du bei der Stange bleibst und mir helfen willst.
Also ich bin da nochmal gedanklich nüchtern rangegangen und habe die Einstellungen geprüft.
Ich sehe im Wireshark einen SSL Vereinbarung und wie dann Daten ausgetauscht werden.
Da verschlüsselt kann ich ja leider nicht reingucken, aber wie gesagt direkt auf die DefaultWebSite bekomme ich die Standard WillkommenSeite.
Wenn ich mich mal von außen durch die installierten virtuellen Verzeichnisse so durchteste, bekomme ich z.B. bei /PowerShell ein Forbidden usw..
Zum weiteren Test habe ich jetzt einfach mal ein virtuelles /Test Verzeichnis im physikalischen wwwroot-Pfad mit einer index.html angelegt, da kann ich dann sofort drauf zugreifen.
Daraufhin bin ich mal in das physikalische Verzeichnis C:\Programme\Microsoft Exch....\V14\ClientAccess\owa gegangen und habe mal dort alles weggesichert und auch eine index.html angelegt und siehe da
... kein Zugriff !
Da passt doch was mit den Zugriffsrechten nicht, oder?
Habe nur leider kein Referenzsystem zum Vergleich übrig.
VG
Uwe
Hi Uwe,
klar bleibe ich da bei der Stange, kann dich ja nicht im regen stehen lassen und außerdem Wurmt mich das selber.
An den rechten kann es eigentlich nicht liegen, weil Intern funktioniert es ja auch ohne Probleme.
Aber überprüfe es mal:
Authentifizierte Benutzer > Lesen
System > Vollzugriff
Administratoren (LokalerServer\LokaleAdminGruppe) > Vollzugriff
Hast du mal versucht extern EWS und ActiveSync auf zu rufen? einfach um aus zu schließen dass es am OWA verzeichnis liegt?!
VG
Criemo
PS: Übrigens html sollte dort nicht gelesen werden können ist ja .Net also wenn müssten es ASPX Dateien sein!
klar bleibe ich da bei der Stange, kann dich ja nicht im regen stehen lassen und außerdem Wurmt mich das selber.
An den rechten kann es eigentlich nicht liegen, weil Intern funktioniert es ja auch ohne Probleme.
Aber überprüfe es mal:
Authentifizierte Benutzer > Lesen
System > Vollzugriff
Administratoren (LokalerServer\LokaleAdminGruppe) > Vollzugriff
Hast du mal versucht extern EWS und ActiveSync auf zu rufen? einfach um aus zu schließen dass es am OWA verzeichnis liegt?!
VG
Criemo
PS: Übrigens html sollte dort nicht gelesen werden können ist ja .Net also wenn müssten es ASPX Dateien sein!
Hallo Criemo,
Hm...
wenn ich /EWS von innen oder draußen aufrufe, kommt die typische Frage "Laden dieser Website fortsetzen(nicht empfohlen)?"
Danach kommt ein HTTP403: Verboten - Die Website hat die Anzeige dieser Webseite abgelehnt.
Gruß
Uwe
Hm...
wenn ich /EWS von innen oder draußen aufrufe, kommt die typische Frage "Laden dieser Website fortsetzen(nicht empfohlen)?"
Danach kommt ein HTTP403: Verboten - Die Website hat die Anzeige dieser Webseite abgelehnt.
Gruß
Uwe
Hallo Uwe,
also wenn solltest du nach dem /EWS auch noch ein /Exchange.aspx dranhängen!
ich denke um mal vorran zu kommen sollten wir jetzt einmal das nachfolgende machen:
Zurücksetzen eines virtuellen Verzeichnisses auf einem Clientzugriffsserver mithilfe der Exchange-Verwaltungskonsole
Bevor Sie dieses Verfahren ausführen können, müssen Ihnen die entsprechenden Berechtigungen zugewiesen werden. Informationen zu den von Ihnen benötigten Berechtigungen finden Sie unter "Zurücksetzen von virtuellen Verzeichnissen auf Clientzugriffsservern" im Thema Clientzugriffsberechtigungen.
Navigieren Sie in der Konsolenstruktur zu Serverkonfiguration > Clientzugriff.
Klicken Sie im Aktionsbereich auf Virtuelles Clientzugriffsverzeichnis zurücksetzen.
Klicken Sie auf der Seite Einführung neben Zurückzusetzendes virtuelles Verzeichnis auf Durchsuchen. Wählen Sie das virtuelle Verzeichnis, das zurückgesetzt werden soll, und klicken Sie auf Weiter. Standardmäßig werden die folgenden virtuellen Clientzugriffsverzeichnisse aufgeführt:
Autodiscover (Standardwebsite)
ecp (Standardwebsite)
EWS (Standardwebsite)
Microsoft-Server-ActiveSync (Standardwebsite)
OAB (Standardwebsite)
owa (Standardwebsite)
Nachdem das Verzeichnis, das zurückgesetzt werden soll, zur Liste unter Zurückzusetzendes virtuelles Verzeichnis hinzugefügt wurde, klicken Sie auf Weiter.
Geben Sie auf der Seite Protokollspeicherort den Pfad und den Dateinamen für die Protokolldatei an, und klicken Sie auf Weiter. Die Protokolldatei umfasst die Einstellungen für das virtuelle Verzeichnis, das zurückgesetzt werden soll. Diese Einstellungen sind möglicherweise nützlich, wenn Sie ein virtuelles Verzeichnis mit denselben Einstellungen wiederherstellen möchten. Die Protokolldatei wird standardmäßig in den Ordner Dokumente auf dem Clientzugriffsserver kopiert.
Klicken Sie auf der Seite Virtuelles Clientzugriffsverzeichnis zurücksetzen auf Zurücksetzen.
Klicken Sie auf der Seite Fertigstellung auf Fertig stellen.
Starten Sie die Internetinformationsdienste (IIS) neu. Sie können die Internetinformationsdienste neu starten, indem Sie an einer Eingabeaufforderung iisreset /noforce ausführen.
Dann können wir uns wenigstens sicher sein, dass es nicht an einem Defekten owa und IIS Config liegt!
VG
Criemo
also wenn solltest du nach dem /EWS auch noch ein /Exchange.aspx dranhängen!
ich denke um mal vorran zu kommen sollten wir jetzt einmal das nachfolgende machen:
Zurücksetzen eines virtuellen Verzeichnisses auf einem Clientzugriffsserver mithilfe der Exchange-Verwaltungskonsole
Bevor Sie dieses Verfahren ausführen können, müssen Ihnen die entsprechenden Berechtigungen zugewiesen werden. Informationen zu den von Ihnen benötigten Berechtigungen finden Sie unter "Zurücksetzen von virtuellen Verzeichnissen auf Clientzugriffsservern" im Thema Clientzugriffsberechtigungen.
Navigieren Sie in der Konsolenstruktur zu Serverkonfiguration > Clientzugriff.
Klicken Sie im Aktionsbereich auf Virtuelles Clientzugriffsverzeichnis zurücksetzen.
Klicken Sie auf der Seite Einführung neben Zurückzusetzendes virtuelles Verzeichnis auf Durchsuchen. Wählen Sie das virtuelle Verzeichnis, das zurückgesetzt werden soll, und klicken Sie auf Weiter. Standardmäßig werden die folgenden virtuellen Clientzugriffsverzeichnisse aufgeführt:
Autodiscover (Standardwebsite)
ecp (Standardwebsite)
EWS (Standardwebsite)
Microsoft-Server-ActiveSync (Standardwebsite)
OAB (Standardwebsite)
owa (Standardwebsite)
Nachdem das Verzeichnis, das zurückgesetzt werden soll, zur Liste unter Zurückzusetzendes virtuelles Verzeichnis hinzugefügt wurde, klicken Sie auf Weiter.
Geben Sie auf der Seite Protokollspeicherort den Pfad und den Dateinamen für die Protokolldatei an, und klicken Sie auf Weiter. Die Protokolldatei umfasst die Einstellungen für das virtuelle Verzeichnis, das zurückgesetzt werden soll. Diese Einstellungen sind möglicherweise nützlich, wenn Sie ein virtuelles Verzeichnis mit denselben Einstellungen wiederherstellen möchten. Die Protokolldatei wird standardmäßig in den Ordner Dokumente auf dem Clientzugriffsserver kopiert.
Klicken Sie auf der Seite Virtuelles Clientzugriffsverzeichnis zurücksetzen auf Zurücksetzen.
Klicken Sie auf der Seite Fertigstellung auf Fertig stellen.
Starten Sie die Internetinformationsdienste (IIS) neu. Sie können die Internetinformationsdienste neu starten, indem Sie an einer Eingabeaufforderung iisreset /noforce ausführen.
Dann können wir uns wenigstens sicher sein, dass es nicht an einem Defekten owa und IIS Config liegt!
VG
Criemo
Hattest du eigentlich auch die Root CA auf deinem Client und dem Server Installiert?
ansonsten schau dir das Tutorial mal an ist zwar für EX2007 aber es sollte im groben dennoch passen!!
VG
Criemo
ansonsten schau dir das Tutorial mal an ist zwar für EX2007 aber es sollte im groben dennoch passen!!
VG
Criemo
Hallo Criemo,
das hatte ich auch schon mal gemacht.
Nun habe ich es aber wiederholt durchgeführt.
Nach dem iireset /noforce ist es das Gleiche wie zuvor.
VG
Uwe
das hatte ich auch schon mal gemacht.
Nun habe ich es aber wiederholt durchgeführt.
Nach dem iireset /noforce ist es das Gleiche wie zuvor.
VG
Uwe
Hallo Uwe,
wie sieht es mit der ROOT CA aus?
ansonsten schau dir das Tutorial mal an ist zwar für EX2007 aber es sollte im groben dennoch passen!!
http://exchangeshell.wordpress.com/2009/09/20/create-ucc-san-private-ca ...
VG
Criemo
wie sieht es mit der ROOT CA aus?
ansonsten schau dir das Tutorial mal an ist zwar für EX2007 aber es sollte im groben dennoch passen!!
http://exchangeshell.wordpress.com/2009/09/20/create-ucc-san-private-ca ...
VG
Criemo
Es gibt derzeit keine authorisierende CA im Netz, bei der ich ein Zertifikat einreichen könnte.
Das verwendete Zertifikat ist ein vom Exchangeserver selbst erstelltes, das dann zwar beim Erstaufruf mangels Verifizierung als bedrohlich angefragt wird, aber nach Bestätigung der Vertrauensstellung bisher keine Probleme bereitet.
Da ein Zertifikat eh bei der Installation des Exchange angelegt wurde, habe ich wie oben erläutert, auf PS-Ebene ein neues mit Aliasen der externen Adressen für den Server gebaut und auch in der Bindung kontrolliert.
Wobei durch die Adress- und Portumsetzung der IIS als anfragende Adresse die interne vom Router bekommt.
Das ist auch der Grund, warum ich so verwundert bin und sich mir der Verdacht aufdrängt, dass der IIS auf der http(s) Ebene zum dem Entschluss kommt, die externe Anfrage zu ignorieren; wenn überhaupt, kann er doch nur dort noch Rückschlüsse auf die ursprüngliche URL ziehen.
Somit drehe ich mich wieder im Kreis und frage mich wie die owa-ASP Seite eigentlich so tickt und an welcher Stelle da ggf. noch eingegriffen werden muss, bzw. welche Einstellung da noch nicht passen könnte.
Die Clients im Netz, die über Outlook zugreifen haben das freilich auch schon mitbekommen und arbeiten aber problemlos mit dem neuen Zertifikat, war also ein weicher Übergang.
VG
Uwe
Das verwendete Zertifikat ist ein vom Exchangeserver selbst erstelltes, das dann zwar beim Erstaufruf mangels Verifizierung als bedrohlich angefragt wird, aber nach Bestätigung der Vertrauensstellung bisher keine Probleme bereitet.
Da ein Zertifikat eh bei der Installation des Exchange angelegt wurde, habe ich wie oben erläutert, auf PS-Ebene ein neues mit Aliasen der externen Adressen für den Server gebaut und auch in der Bindung kontrolliert.
Wobei durch die Adress- und Portumsetzung der IIS als anfragende Adresse die interne vom Router bekommt.
Das ist auch der Grund, warum ich so verwundert bin und sich mir der Verdacht aufdrängt, dass der IIS auf der http(s) Ebene zum dem Entschluss kommt, die externe Anfrage zu ignorieren; wenn überhaupt, kann er doch nur dort noch Rückschlüsse auf die ursprüngliche URL ziehen.
Somit drehe ich mich wieder im Kreis und frage mich wie die owa-ASP Seite eigentlich so tickt und an welcher Stelle da ggf. noch eingegriffen werden muss, bzw. welche Einstellung da noch nicht passen könnte.
Die Clients im Netz, die über Outlook zugreifen haben das freilich auch schon mitbekommen und arbeiten aber problemlos mit dem neuen Zertifikat, war also ein weicher Übergang.
VG
Uwe
Hallo Criemo,
nun kommen wir vielleicht doch ein Stück weiter.
Ich habe einmal die URL aus dem internen Zugriff, wenn ich im Anmeldefenster stehe kopiert und diese dann für den externen Zugriff genommen und die enthaltenen Adressen gepatched.
Und siehe da, es geht !
Das sieht dann wie folgt aus:
https://<externer-ip>:8443/owa/auth/logon.aspx?replaceCurrent=1&url=https%3a%2f%2f<externe-ip>%2fowa%2f
oder auch mit
https://<externe-ip>:8443/owa/auth/logon.aspx?
Nur mit
https://<externe-ip>:8443/owa
geht es nicht.
Was ist da von mir beim IIS nicht berücksichtigt worden?
VG
Uwe
nun kommen wir vielleicht doch ein Stück weiter.
Ich habe einmal die URL aus dem internen Zugriff, wenn ich im Anmeldefenster stehe kopiert und diese dann für den externen Zugriff genommen und die enthaltenen Adressen gepatched.
Und siehe da, es geht !
Das sieht dann wie folgt aus:
https://<externer-ip>:8443/owa/auth/logon.aspx?replaceCurrent=1&url=https%3a%2f%2f<externe-ip>%2fowa%2f
oder auch mit
https://<externe-ip>:8443/owa/auth/logon.aspx?
Nur mit
https://<externe-ip>:8443/owa
geht es nicht.
Was ist da von mir beim IIS nicht berücksichtigt worden?
VG
Uwe
Zu früh gefreut,
es kommt zwar das Anmeldefenster, aber nach dem Anmelden wieder Die Seite kann nicht angezeigt werden.
Trotzdem, zeigt das doch schon die Richtung an.
VG
Uwe
es kommt zwar das Anmeldefenster, aber nach dem Anmelden wieder Die Seite kann nicht angezeigt werden.
Trotzdem, zeigt das doch schon die Richtung an.
VG
Uwe
Hi Uwe,
Was passiert denn wenn du auf dem Exchange mal https://localhost/owa aufrufst?
Kannst du es mal ohne Port forwarding probieren?
Ich glaube dass es hier der Hase liegt!
Die URL die du da anzeigst? Hast du URL Hardening aktiviert?
Setzt du einen Reverse Proxy ein?
VG
Criemo
Was passiert denn wenn du auf dem Exchange mal https://localhost/owa aufrufst?
Kannst du es mal ohne Port forwarding probieren?
Ich glaube dass es hier der Hase liegt!
Die URL die du da anzeigst? Hast du URL Hardening aktiviert?
Setzt du einen Reverse Proxy ein?
VG
Criemo
Hallo Criemo,
mit https://localhost/owa funktioniert es auch.
Leider kann ich nicht so weiteres das Forwarding abschalten, da ich nicht auf den Providerrouter keinen direkten Zugriff habe.
Müsste ich in Auftrag geben, ist aber nicht unmöglich.
Nein, einen Proxy habe ich nicht zwischengeschaltet.
Von draußen geht es auf den eben erwähnten Router, der die eingehenden Pakete des betreffenden Ports auf die dahinter liegende Appliance wirft.
Diese ist wieder in meinem Zugriff und setzt den externen Port auf 443 um, sich selber als Absender via NAT ein und leitet die Anfrage an den Exchangeserver.
Das NAT habe ich zuletzt noch hinzugenommen, da ich am Anfang erst ohne angefangen habe und aufgrund des Problems die Möglichkeit ausschließen wollte, dass der Exchange sich an der "fremden" Absenderadresse stört; so kommt für ihn die Anfrage adressseitig quasi von innen.
Der Datenverkehr scheint ja auch soweit zu klappen.
Ein URL Hardening ist an der Stelle nicht eingerichtet, es sei denn, der IIS macht das selber.
Da habe ich aber keine aktive Aktien dran und müsste mir das Thema im IIS auch erstmal anlesen.
VG
Uwe
mit https://localhost/owa funktioniert es auch.
Leider kann ich nicht so weiteres das Forwarding abschalten, da ich nicht auf den Providerrouter keinen direkten Zugriff habe.
Müsste ich in Auftrag geben, ist aber nicht unmöglich.
Nein, einen Proxy habe ich nicht zwischengeschaltet.
Von draußen geht es auf den eben erwähnten Router, der die eingehenden Pakete des betreffenden Ports auf die dahinter liegende Appliance wirft.
Diese ist wieder in meinem Zugriff und setzt den externen Port auf 443 um, sich selber als Absender via NAT ein und leitet die Anfrage an den Exchangeserver.
Das NAT habe ich zuletzt noch hinzugenommen, da ich am Anfang erst ohne angefangen habe und aufgrund des Problems die Möglichkeit ausschließen wollte, dass der Exchange sich an der "fremden" Absenderadresse stört; so kommt für ihn die Anfrage adressseitig quasi von innen.
Der Datenverkehr scheint ja auch soweit zu klappen.
Ein URL Hardening ist an der Stelle nicht eingerichtet, es sei denn, der IIS macht das selber.
Da habe ich aber keine aktive Aktien dran und müsste mir das Thema im IIS auch erstmal anlesen.
VG
Uwe
Hi Uwe,
ich fasse mal zusammen:
Intern geht der Zugriff
auf dem Localhost geht der Zugriff
Ergo Kein Problem mit OWA bzw IIS
2. Möglichkeiten
entweder liegt es noch an dem externen Zertifikat, welches du verwendest oder aber am Portforwarding bzw. am NAT
VG
Criemo
ich fasse mal zusammen:
Intern geht der Zugriff
auf dem Localhost geht der Zugriff
Ergo Kein Problem mit OWA bzw IIS
2. Möglichkeiten
entweder liegt es noch an dem externen Zertifikat, welches du verwendest oder aber am Portforwarding bzw. am NAT
VG
Criemo
Hallo Criemo,
ich werden zusätzlich den Port 443 einrichten lassen, kann man ja später ggf. wieder rausnehmen.
Nächste Woche gehe ich mal vor Ort zwischen Router und Appliance und werde aus dem "Transportnetz" einen Zugriff versuchen.
Vielleicht kommt dann ja mehr Licht ins Dunkel.
Danke für die Unterstützung, ich melde mich wieder und berichte.
Wäre schön, wenn du mich dann ggf. wieder weiter unterstützen könntest.
Schönes WE und VG
Uwe
ich werden zusätzlich den Port 443 einrichten lassen, kann man ja später ggf. wieder rausnehmen.
Nächste Woche gehe ich mal vor Ort zwischen Router und Appliance und werde aus dem "Transportnetz" einen Zugriff versuchen.
Vielleicht kommt dann ja mehr Licht ins Dunkel.
Danke für die Unterstützung, ich melde mich wieder und berichte.
Wäre schön, wenn du mich dann ggf. wieder weiter unterstützen könntest.
Schönes WE und VG
Uwe
Hi Uwe,
klar kein Problem ich bin hier
Schönes WE und Viele Grüße
VG
Mirco
klar kein Problem ich bin hier
Schönes WE und Viele Grüße
VG
Mirco
Hallo Criemo,
am Ende war es so was von trivial.
Es heißt ja Google ist dein Freund naja..
Ich bin nach diverser Recherche zu dem Thema über verschiedene Lösungsansätze von TMG und ReverseProxy dem Bock aufgesessen, dass es laut gelesener Aussagen ausreichen soll, einen externen Port auf den internen 43 umzuleiten.( Mit allen Vor- und Nachteilen).
Was aber leider keine Erwähnung fand, ist, dass die ASPX Integration des OWA gleich mal einen URL Redirect macht; dabei geht dann logischerweise bei einer Portumsetzung der externe Quellport verloren; en bekommt das OWA ja nicht mit.
Meine Überlegungen waren zu sehr von der Aussage geprägt, dass es gehen soll und ich Mangels bisheriger Beschäftigung mit dem IIS und OWA zuerst eine falsche Konfiguration etc. vermutete und weil ich mir die URL beim internen Zugriff nicht genau angesehen habe, bin ich da erst viel später darauf gekommen.
Also extern wie intern auf 443 belassen und schon geht es, kein Fehler mehr !
Nun kann noch zu Absicherung ein ReverseProxy dazwischen und es sollte soweit OK sein.
Danke nochmal
und VG
Uwe
am Ende war es so was von trivial.
Es heißt ja Google ist dein Freund naja..
Ich bin nach diverser Recherche zu dem Thema über verschiedene Lösungsansätze von TMG und ReverseProxy dem Bock aufgesessen, dass es laut gelesener Aussagen ausreichen soll, einen externen Port auf den internen 43 umzuleiten.( Mit allen Vor- und Nachteilen).
Was aber leider keine Erwähnung fand, ist, dass die ASPX Integration des OWA gleich mal einen URL Redirect macht; dabei geht dann logischerweise bei einer Portumsetzung der externe Quellport verloren; en bekommt das OWA ja nicht mit.
Meine Überlegungen waren zu sehr von der Aussage geprägt, dass es gehen soll und ich Mangels bisheriger Beschäftigung mit dem IIS und OWA zuerst eine falsche Konfiguration etc. vermutete und weil ich mir die URL beim internen Zugriff nicht genau angesehen habe, bin ich da erst viel später darauf gekommen.
Also extern wie intern auf 443 belassen und schon geht es, kein Fehler mehr !
Nun kann noch zu Absicherung ein ReverseProxy dazwischen und es sollte soweit OK sein.
Danke nochmal
und VG
Uwe
Hi Uwe,
wunderbar. das freut mich, dass es funktioniert!
Makiere das Thema bitte als gelöst.
VG
Criemo
wunderbar. das freut mich, dass es funktioniert!
Makiere das Thema bitte als gelöst.
VG
Criemo
