39949
18.12.2006, aktualisiert um 12:17:14 Uhr
8824
1
0
RPC over Http funktioniert nicht
Hallo, ich weiß, dass das Thema RPC over Http hier schon mehrfach ausführlich besprochen wurde ... nur leider nicht mit Antworten, die mein Problem lösen.
Also ich habe Exchange 2003 auf Windows 2003 Server laufen. OWA funktioniert bestens, OMA auch. Mit RPC bin ich soweit, dass meines Erachtens nach auf dem Server alles so ist, wie es in unzählichen Beiträgen beschrieben wurde. Ich komme auch bei meineIP/rpc an die Anmeldung, bei erfolgreicher Anmeldung an diese fehlerhafte Seite oder bei meineIP/rpc/rpcproxy.dll auf eine leere Seite.
RPSProxy steht im Ereignisprotokoll auch als gestartet.
Ich habe auch schon folgende Variationen durchgespielt. Mit und ohne SSL im virtuellen Verzichnis Exchange, mit und ohne formularbasierter Anmeldung in virtuellen Standardserver, mit Standardauthentifizierung oder mit Anonymous User im virtuellen Verzeichnis Exchange.
Und nun seid ihr dran
Ich hätte zwei konkrete Fragen ...
1. Benötigt RPC einen gesonderten Port auf der Firewall? Ich habe hier nur den SSL-Port 443 offen.
2. Es gab mal einige Hinweise zum Zertifikat. Ich habe mein Serverzertifikat auf dem Client zwar installiert - dies erzeugt z.B. im Explorer bei der Überprüfung dennoch eine Fehlermeldung, da mein Zertifikat ja von meinem internen Server ausgestellt wurde, sagen wir mal z.B. ABC1, ich übers Web aber natürlich auf z.B. mail.meinedomain.de oder direkt auf die öffentliche IP zugreife. Wir haben hier nur den Mailserver im Hause, unsere Webseite www.meinedomain.de liegt woanders. Kann das ein Problem sein?
Ich hoffe, ihr könnt mir helfen.
Michael Wendelstorf
Also ich habe Exchange 2003 auf Windows 2003 Server laufen. OWA funktioniert bestens, OMA auch. Mit RPC bin ich soweit, dass meines Erachtens nach auf dem Server alles so ist, wie es in unzählichen Beiträgen beschrieben wurde. Ich komme auch bei meineIP/rpc an die Anmeldung, bei erfolgreicher Anmeldung an diese fehlerhafte Seite oder bei meineIP/rpc/rpcproxy.dll auf eine leere Seite.
RPSProxy steht im Ereignisprotokoll auch als gestartet.
Ich habe auch schon folgende Variationen durchgespielt. Mit und ohne SSL im virtuellen Verzichnis Exchange, mit und ohne formularbasierter Anmeldung in virtuellen Standardserver, mit Standardauthentifizierung oder mit Anonymous User im virtuellen Verzeichnis Exchange.
Und nun seid ihr dran
Ich hätte zwei konkrete Fragen ...
1. Benötigt RPC einen gesonderten Port auf der Firewall? Ich habe hier nur den SSL-Port 443 offen.
2. Es gab mal einige Hinweise zum Zertifikat. Ich habe mein Serverzertifikat auf dem Client zwar installiert - dies erzeugt z.B. im Explorer bei der Überprüfung dennoch eine Fehlermeldung, da mein Zertifikat ja von meinem internen Server ausgestellt wurde, sagen wir mal z.B. ABC1, ich übers Web aber natürlich auf z.B. mail.meinedomain.de oder direkt auf die öffentliche IP zugreife. Wir haben hier nur den Mailserver im Hause, unsere Webseite www.meinedomain.de liegt woanders. Kann das ein Problem sein?
Ich hoffe, ihr könnt mir helfen.
Michael Wendelstorf
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 46826
Url: https://administrator.de/forum/rpc-over-http-funktioniert-nicht-46826.html
Ausgedruckt am: 27.12.2024 um 15:12 Uhr
1 Kommentar
Sieh mal: RPC over Http funktioniert nicht
Exchange Ports
Ports can be defined as communications channels. Different networking protocols operate on different ports allowing multiple applications to communicate through one connection. We all know HTTP communicates through TCP port 80, but what about all the different Exchange services?
Microsoft Exchange utilizes a number of ports during normal operation. You are probably already familiar with the basic port/service combinations, but as a review I will list them.
Simple Mail Transport Protocol - SMTP uses TCP 25
Post Office Protocol 3 - POP3 uses TCP 110 and TCP 995 (SSL)
Network News Transfer Protocol - NNTP uses TCP 119 and TCP 563 (SSL)
Internet Messaging Access Protocol 4 - IMAP4 uses TCP 143 and 993 (SSL)
World Wide Web Publishing - WWW uses TCP 80 and TCP 443 (SSL)
But what about all the other "background" services?
Exchange System Manager uses WMI to perform management tasks on Exchange servers. WMI uses RPC which requires TCP 135 as well as an assortment of random UDP ports above 1024.
The Exchange Information Store receives traffic on TCP port 135 except when RPC over HTTP is being used when TCP port 6001 is also used for inbound communications. The Information Store uses outbound communications to inform clients of new mail. An Outlook client listens on a random UDP port. If the client is accessing Exchange through RPC over HTTPS direct server polling is used instead and the ports are defined by the administrator.
Port wise, Exchange System Attendant is the most complicated of Exchange services. SA uses inbound TCP 135, but it also uses random ports above 1024 for RPC end points and can change when the SA service is restarted. When using RPC over HTTP, the administrator would have configured TCP ports 6002-6004 for inbound communications.
The Exchange Routing Engine routes traffic between the Exchange servers within your Exchange organization over TCP port 691.
The Site Replication Service (SRS) also uses RPC. As mentioned, RPC uses TCP port 135. SRS can use additional random TCP ports for outbound communications and TCP port 379 for inbound communications.
Active Directory Connector sends trafic outbound over TCP 379 and 389. It does not accept any inbound traffic.
Lastly, the Message Transfer Agent (MTA) is used to communicate with Exchange 5.5 servers and other mail servers that use X.400 protocol. Again, the MTA uses RPC over TCP 135 and TCP 102 for X.400.
Exchange Ports
Ports can be defined as communications channels. Different networking protocols operate on different ports allowing multiple applications to communicate through one connection. We all know HTTP communicates through TCP port 80, but what about all the different Exchange services?
Microsoft Exchange utilizes a number of ports during normal operation. You are probably already familiar with the basic port/service combinations, but as a review I will list them.
Simple Mail Transport Protocol - SMTP uses TCP 25
Post Office Protocol 3 - POP3 uses TCP 110 and TCP 995 (SSL)
Network News Transfer Protocol - NNTP uses TCP 119 and TCP 563 (SSL)
Internet Messaging Access Protocol 4 - IMAP4 uses TCP 143 and 993 (SSL)
World Wide Web Publishing - WWW uses TCP 80 and TCP 443 (SSL)
But what about all the other "background" services?
Exchange System Manager uses WMI to perform management tasks on Exchange servers. WMI uses RPC which requires TCP 135 as well as an assortment of random UDP ports above 1024.
The Exchange Information Store receives traffic on TCP port 135 except when RPC over HTTP is being used when TCP port 6001 is also used for inbound communications. The Information Store uses outbound communications to inform clients of new mail. An Outlook client listens on a random UDP port. If the client is accessing Exchange through RPC over HTTPS direct server polling is used instead and the ports are defined by the administrator.
Port wise, Exchange System Attendant is the most complicated of Exchange services. SA uses inbound TCP 135, but it also uses random ports above 1024 for RPC end points and can change when the SA service is restarted. When using RPC over HTTP, the administrator would have configured TCP ports 6002-6004 for inbound communications.
The Exchange Routing Engine routes traffic between the Exchange servers within your Exchange organization over TCP port 691.
The Site Replication Service (SRS) also uses RPC. As mentioned, RPC uses TCP port 135. SRS can use additional random TCP ports for outbound communications and TCP port 379 for inbound communications.
Active Directory Connector sends trafic outbound over TCP 379 and 389. It does not accept any inbound traffic.
Lastly, the Message Transfer Agent (MTA) is used to communicate with Exchange 5.5 servers and other mail servers that use X.400 protocol. Again, the MTA uses RPC over TCP 135 and TCP 102 for X.400.