djrace
Goto Top

Exchange 2003 von außen OWA geht RPC OVER HTTP mit Outlook geht nicht

Hi,

folgendes Szenario. Windows 2003 Server Standard Edition. Exchange 2003 Standard Server. IIS + SSL konifguriert. OWA funktioniert einwandfrei mit https://domain/exchange. Keine Fehler keine Probleme. Das einzige man bekommt beim aufrufen immer die Meldung das das Zertifikat nicht zu einer Zertifzierungstelle zurückverfolgt werden kann.

So nun zum eigentlichen Problem. Ich will mich von extern mit Outlook an der Server connecten. Habe rpc over http/s installiert. Diese rpc verzeichnis ist im IIS Manager auch zu sehen und wenn ich https://domain/rpc/rpcproxy.dll aufrufe und den entsprechenden Benutzername angebe kommt auf die entsprechend leere Seite wie bei Mircosoft Hilfe beschrieben. In den Ereignislogs steht dann auf das der RPC-Proxy erfolgreich gestartet wurde. Im selben Netzwerk funnktioniert die connection zum exchange mit outlook allerdings steht bei verbindung tcp/ip und nicht HTTPS. Es ist keine Firewall installiert auf dem Server. Server hängt hinter Router. Port 443 durchgeleitet.

Bin hier fast am verzweifeln warum das net will. Das einzige was mir da einfällt wäre noch das SSL Zertifikat was ich direkt auf meinem Server erstellt habe. Wenn ich auf dem Server direkt https://domain/exchange aufrufe kommt dann nachdem ich das Zertifikat einmal installiert habe keine Meldung mehr. Bei externen Clients die die Seite aufrufen kommt wie gesagt das das Sicherheitszertifikat von einer Firma ausgestellt wurde die nciht vertrauenswürdig ist. Habe das zertifikat auch in die vertrauenswürdigen exprotiert. Und trotzdem ist das Outlook von extern zu blöde den Exchange server zu finden. Ich weiß net mehr was ich falsch mache.

Hier vielleicht noch einer ne Idee. Danke im Vorraus

Content-Key: 34417

Url: https://administrator.de/contentid/34417

Ausgedruckt am: 19.03.2024 um 08:03 Uhr

Mitglied: unzhurst
unzhurst 19.06.2006 um 10:17:49 Uhr
Goto Top
Hallo djrace,

das erste Problem ist mit Sicherheit das SSL Zertifikat.
Wenn du von einem Client aus https://server/exchange aufrufst darf keine
Fehlermeldung/Warnung kommen. Um die zu erreichen musst du das Root-Zertifikat
deines SSL-Zertifikats auf den Clients installieren.

Wenn der Fehler weg ist kann man weiter schauen.

Gruß
Patrick
Mitglied: djrace
djrace 19.06.2006 um 10:27:31 Uhr
Goto Top
So,

danke für den Tipp.
Habe das dann auch gleich gemacht. Und siehe da jetzt bekomme ich beim aufrufen keine Meldung mehr face-smile

Allerdings habe ich gleich danach wieder mit Outlook probieren wollen. Und er hat gleich wieder nachdem ích aufgefordert wurde User und Passwort anzugeben im Verbindungsstatus quasi abgebrochen und dann die Meldung gebracht das er den Exchange Server nicht finden kann.
Mitglied: unzhurst
unzhurst 19.06.2006 um 10:29:57 Uhr
Goto Top
Die Abfrage bzgl. Benutzer/Kennwort wäre i.O.!
Du Authentifizierst dich am IIS, deshalb die Abfrage.
Hast du es mit domäne\benutzername und Kennwort versucht?

Gruß
Patrick
Mitglied: djrace
djrace 19.06.2006 um 10:46:26 Uhr
Goto Top
Eine sehr interessante Entdeckung:

Erst zu deiner Frage. Ja den Domänennamen habe ich davor geschrieben. Habe schon sämtliches Zeug probiert.

Was mir jetzt aufgefallen ist.

Wenn ich was falsches eingebe an User und Passwort bringt er das Fenster wieder und wenn ich dann was richtiges eingebe versucht er aber es geht net hat der user da keine rechte oder was?

EDIT
ach ne kann ja net sein denn der User geht ja wenn ich es mit dem im selben Netzwerk probiere
Mitglied: unzhurst
unzhurst 19.06.2006 um 10:51:13 Uhr
Goto Top
Hab mal was zum lesen für dich ;)
http://www.msxfaq.net/clients/rpchttp.htm
http://www.msisafaq.de/Anleitungen/2004/Firewallrichtlinien/RPCHTTPS.ht ...

Schau dir mal die ISA-FAQ Seite an... Bis Punkt 4 ist es für dich interessant.
Hast du die Regkeys gesetzt?! Bzw. falls DC und Exchange auf dem Server läuft,
dann nur den ersten?

Gruß
Patrick
Mitglied: djrace
djrace 19.06.2006 um 10:54:39 Uhr
Goto Top
die regkeys sind korrekt gesetzt und es läuft nur exchange und kein DC

deine Links kenne ich bereits ich versuche mein Problem seit 2 Tagen zu lösen gibt keine Inetseite die ich noch net kenne
face-smile
Mitglied: unzhurst
unzhurst 19.06.2006 um 11:00:11 Uhr
Goto Top
ok - das ist doch schon mal was...

Wie siehts mit deiner Outlook-Konfig aus? Du hast unter den Verbindungsoptionen
für HTTP folgendes einsgestellt:
- Servername: (z.B.) owa.externerdomainname.de
- Häckchen für SSL ist drin (zweites nicht)
- Authentifizierung steht auf "Standard"

Richtest du das Outlook-Profil gerade neu ein, oder änderst du bei einem
bereits funktionierenden Outlook die Konfig? In der Basis-Konfig der
Exchange-Einstellungen muss der interne Servername stehen.

Wie siehts in den Eventlogs des GCs und des Exchange aus?

Gruß
Patrick
Mitglied: djrace
djrace 19.06.2006 um 11:38:30 Uhr
Goto Top
outlook habe ich richtig konfiguriert 100%

wo finde ich die eventlogs vom exchange? bzw. wo stelle ich sie ein?
Mitglied: unzhurst
unzhurst 19.06.2006 um 11:59:08 Uhr
Goto Top
Als erstes wäre da das Ereignisportokoll des Servers...
Das IIS-Log usw. findest du wie hier beschrieben unter "Fehlersuche":
http://www.msxfaq.net/clients/rpchttp.htm

Gruß
Mitglied: djrace
djrace 19.06.2006 um 18:01:51 Uhr
Goto Top
Hi,

so hab ihn jetzt soweit das sich mein Outlook connected.

Im Verbindungsstatus steht die Schnittstelle die Verbindung HTTPS Die Anfragen die Reaktionszeit usw.....

Das Problem ist das es sowas von langsam geht...... 7/14 Anfragen waren fehlerhaft und die Reaktionszeit ist sau hoch und nach ner Zeit hört er auf das Konto zu übertragen

Der Client Rechner hat keine Firewall oder sonstige Programme und der Server auch net...


woran liegt das nun wieder das das soooooooooo langsaaammm geht?!?!??!
Mitglied: unzhurst
unzhurst 19.06.2006 um 19:16:15 Uhr
Goto Top
Wie verbindest du dich? Direkt im Firmen-LAN oder übers Internet?
Wenn übers Internet, wie sind die beiden Seiten angebunden?

Wenn ich sowas einrichte habe ich normalerweise auf der Seite des Exchange so 2MBit
SDSL und beim Client irgendein ADSL. Da sollte die Perfomance auf jeden Fall reichen.

Gruß
Patrick
Mitglied: djrace
djrace 19.06.2006 um 22:44:21 Uhr
Goto Top
Ich glaube ich habe massive DNS auflösungsprobleme auf dem Server.

Wenn ich das Outlook direkt auf dem Server starte und zu dem Exchange verbinde geht das natürlich sau schnell.

wenn ich in dem selben netzwerk auf nem anderen pc outlook mit dem exchange sync. will gehts schon los...... alles total lahm nach der Username und passwort abfrage

und von einem externen client genauso


mir ist dabei in den iis logs folgendes aufgefallen

2006-06-19 16:15:17 60537 192.168.150.92 443 HTTP/1.1 RPC_IN_DATA /rpc/rpcproxy.dll?DW-W2K:1027 400 1 Connection_Dropped DefaultAppPool
2006-06-19 16:21:14
61959 192.168.150.92 443 HTTP/1.1 RPC_IN_DATA /rpc/rpcproxy.dll?DW-W2K:593 400 1 BadRequest DefaultAppPool
2006-06-19 16:21:47 **61959 192.168.150.92 443 HTTP/1.1 RPC_IN_DATA /rpc/rpcproxy.dll?DW-W2K:593 400 1 Connection_Dropped DefaultAppPool


diese bad requests wiederholen sich andauernd

wie wie vorher schon gesagt in dem verbindungsstatus von dem outlook steht bei der reaktionszeit eine 2000 vom externen clienten und beim internen ne 800 wenn das die ping zeit sein soll na dann is kein wunder das das net vorwärts geht......

aufgrund dessen das der selbe fehler auch im netzwerk auftritt leigt es net an der leitung......server hängt an DSL 2000 mit Uploaderhöhung Client hat DSL 6000 mit Fastpath

Es muss irgendein namensauflösungsproblem sein oder so deswegen bestimmt auf diese bad requests.

oder was meinst du dazu

naja morgen is ja auch noch ein Tag mal sehen was der bringt face-smile
Mitglied: unzhurst
unzhurst 20.06.2006 um 07:44:58 Uhr
Goto Top
Ich könnte mir eher vorstellen dass der IIS irgendein Problem hat.
DNS geht oder geht nicht - d.h. entweder sagt er dir er findet den Server
nicht, oder er findet ihn halt und geht zum nächsten Schritt.

Gruß
Patrick
Mitglied: Liberation
Liberation 07.12.2006 um 12:53:41 Uhr
Goto Top
Wo lag damals der Fehler bei dir?

Habe scheinbar das selbe Problem wie Du mein Outlook will sich einfach nicht über RPC-HTTPS verbinden.