none
RPC over HTTP -> Outlook Timeouts RRS feed

  • Frage

  • Hallo.

    Wir haben hier 2 Exchange 2007 und einen RD-Gateway. OS 2008 bzw 2008 R2 Um die Zertifikatsproblematik mit einem SAN zu erschlagen, haben wir auf dem RD-Gateway ebenfalls RPC over HTTP installiert, entsprechend konfiguriert und dann die Gateway statt der OWA URL in Outlook als Proxy eingetragen. Funktioniert auch alles so weit, Outlook ist auch insgesamt nicht langsamer geworden, allerdings kommt es seit dem immer wieder zu Ausetzern. Für einige Sekunden "Kein Rückmeldung" oder Outlook friert ganz ein, und meldet dann das Exchange nicht zur Verfügung steht. Da die RPC over HTTP Funktion nicht zwangsläufig an den Exchange gebunden ist - zumindest habe ich nichts gegenteiliges gefunden - spricht ja nichts dagegen es so zu handhaben. Techisch sollte und ist es ja auch kein Problem.

    Im Verbindungsstatus sieht man manch mal das versucht wir die Verbindung wieder herzustellen. Im Eventlog nur die Einträge von Outlook das die Verbindung getrennt, bzw. wieder aufgebaut wurde. Die Aussetzer sind aber von beidem unabhängig, sind alos auch wenn im Eventlog kein Eintrag oder Unterbrechung im Verbindungsstatus.

    Hat jemand ein Idee/Vermutung woher oder wie es zu diesen Timeouts kommt?

    Gruss Ingo

    Sonntag, 5. Dezember 2010 14:16

Antworten

  • Hallo.

    Also wir schliessen das hier mal. Genug genervt. Ich denke nicht das wir der Sache so auf die Spur kommen. Entweder konfigurieren wir die Clients wieder auf Mapi, oder machen einen Call bei MS auf.

    Danke für Eure Unterstützung. Schade das wir das Problem nicht lösen konnten.

    Gruss Ingo

    • Als Antwort markiert Ingo Schneider Freitag, 10. Dezember 2010 14:55
    Freitag, 10. Dezember 2010 14:55

Alle Antworten

  • Hi Ingo Schneider,

    Hallo.

    Wir haben hier 2 Exchange 2007 und einen RD-Gateway. OS 2008 bzw 2008 R2 Um die Zertifikatsproblematik mit einem SAN zu erschlagen, haben wir auf dem RD-Gateway ebenfalls RPC over HTTP installiert, entsprechend konfiguriert und dann die Gateway statt der OWA URL in Outlook als Proxy eingetragen. Funktioniert auch alles so weit, Outlook ist auch insgesamt nicht langsamer geworden, allerdings kommt es seit dem immer wieder zu Ausetzern. Für einige Sekunden "Kein Rückmeldung" oder Outlook friert ganz ein, und meldet dann das Exchange nicht zur Verfügung steht. Da die RPC over HTTP Funktion 
    nicht zwangsläufig an den Exchange gebunden ist - zumindest habe ich nichts gegenteiliges gefunden - spricht ja nichts dagegen es so zu handhaben. Techisch sollte und ist es ja auch kein Problem.

    Möglich ja, aber die bist das eine Problem umgangen und hast dir
    wahrscheinlich einen neuen eingehandelt! Super Würgaround! ;) Möchtest du
    nicht doch nochmal probieren alles direkt über den Server anzuwickeln? 

    Im Verbindungsstatus sieht man manch mal das versucht wir die Verbindung wieder herzustellen. Im Eventlog nur die Einträge von Outlook das die Verbindung getrennt, bzw. wieder aufgebaut wurde. Die Aussetzer sind aber von beidem unabhängig, sind alos auch wenn im Eventlog kein Eintrag oder Unterbrechung im Verbindungsstatus.

    Hast du mal das das DiagnostikLogging am Exchange erhöht - siehe MSExchangeSA:
    http://www.msxfaq.de/admin/diag2k7.htm

    Hier noch etwas in Richtung RPC Troubleshooting:
    http://support.microsoft.com/kb/325930/en-us

    Viele Grüße
    Christian

    Montag, 6. Dezember 2010 05:58
    Moderator
  • Guten Morgen Christian.

    Na ja, man muss das Geld ja nicht unnötig ausgeben, und bei den Test mit ein paar PCs war der Fehler nicht.

    Denkst Du es geht nicht?

    Laut dem von Dir verlinkten MS Dokument solten folgende Protokolle eingetragen sein.

    ncalrpc,ncacn_ip_tcp,ncacn_spx,ncacn_np,netbios,ncacn_vns_spp
    Bei beiden Exchange hier hat es nur Einträge.
    ncalrpc,ncacn_ip_tcp
    Da das Dokument schon etwas älter ist sich auch NT 4 und Ex 2000 und Ex 2003 bezieht, gehe ich mal davon aus das das in Ordnung ist.
    Aber auf dem Gateway fehlen natürlich die Einträge die sich auf den Exchange Schlüssel beziehen. Ist ja auch kein Exchange drauf sondern nur rpc over http installiert.
    Bei den Client Protokollen fehlt beim Exchange interessanterweise, weil da ist ja auch die Funktion rpc over http installiert, ncacn_np. Das Setup wird schon nichts falsch gemacht haben und da ncacn_http beim Exchange und Gateway als erstes steht, sollte ja passen.
    Bei der Protokollierung gibt es leider keine Eintrag mit dem man rpc over http logen kann. Da muss ich erst mal schauen was ich hier sinnvollerweise einschalte.
    Gruss Ingo
    Montag, 6. Dezember 2010 07:05
  • Hi Ingo,

    Na ja, man muss das Geld ja nicht unnötig ausgeben, und bei den Test mit ein paar PCs war der Fehler nicht.

    Haben wir auch nicht - ich nutz eine lokale CA und falls ein externer Client
    auch per HTTPS ran möchte, bekommt er das RootCert untergejubelt...

    Denkst Du es geht nicht?

    Doch das muss gehen, den viele lassen es über eine Proxy laufen...

    Bei den Client Protokollen fehlt beim Exchange interessanterweise, weil da ist ja auch die Funktion rpc over http installiert, ncacn_np. Das Setup wird schon nichts falsch gemacht haben und da ncacn_http beim Exchange und Gateway als erstes steht, sollte ja passen.

    Stell da auch erstmal nichts ein, sondern versuch nachzuvollziehen, was da
    passiert - Use Network Monitor to identify RPC issues. Schau auch mal bei
    Frank zu dem Thema vorbei:

    Bei der Protokollierung gibt es leider keine Eintrag mit dem man rpc over http logen kann. Da muss ich erst mal schauen was ich hier sinnvollerweise einschalte.

    Da das keine permanenten Probleme sind, vermute ich, dass du an irgendwelche
    Limits des Exchange stößt:
    http://technet.microsoft.com/en-us/library/ff477612.aspx

    Schau mal hier - ist jetzt zwar Exchange 2010 mit Outlook 2003, aber hier
    kommt es duch Limits auch zu Verbindungsfehler:
    http://social.technet.microsoft.com/Forums/de-DE/exchange_serverde/thread/88a4c5a0-7574-463e-be78-ae1602ddf05a

    Exchange ist UptoDate und mit SP3 versehen?

    Viele Grüße
    Christian

    Montag, 6. Dezember 2010 08:06
    Moderator
  • Hallo Christian.

    Danke für die Tipps und die Links. Schaue ich mir an.

    Nein SP3 ist noch nicht drauf. Schon versucht, hat aber mit diveresen Fehlermeldungen, allerdings nur Kleinkram, abgebrochen. Hatte aber noch keine Zeit nach dem Problem zu schauen.

    Gruss Ingo

     

    Montag, 6. Dezember 2010 08:36
  • Hi Ingo,

    Nein SP3 ist noch nicht drauf. Schon versucht, hat aber mit diveresen Fehlermeldungen, allerdings nur Kleinkram, abgebrochen. Hatte aber noch keine Zeit nach dem Problem zu schauen.

    das würde ich auf jeden Fall noch nachholen - es wirkt wie eine
    Neuinstallation, behebt einige Fehler und bringt Verbesserungen...

    Viele Grüße
    Christian

    Montag, 6. Dezember 2010 14:16
    Moderator
  • Hallo Christian.

    Geht nicht. Kleine Fehler habe ich alle weg. Aber den untenstehenden finde ich keine Lösung. Ich weiss nicht wo die IP 0.0.0.0 herkommt.

    Gruss Ingo

    Zusammenfassung: 3 Element(e). Erfolgreich: 3, Fehler: 0.
    Verstrichene Zeit: 00:00:42


    Hub-Transport-Funktion Voraussetzungen
    Abgeschlossen

    Warnung:
    Setup kann keine Verbindung mit dem primären DNS-Server (0.0.0.0) über den TCP-Port 53 herstellen. Überprüfen Sie, ob die IP-Adresse des DNS-Servers richtig und der DNS-Server erreichbar ist.

    Warnung:
    Setup kann nicht überprüfen, ob der 'Host' (A)-Datensatz für diesen Computer in der DNS-Datenbank auf Server 0.0.0.0 vorhanden ist.


    Verstrichene Zeit: 00:00:30


    ClientAccess-Funktion Voraussetzungen
    Abgeschlossen

    Warnung:
    Setup kann keine Verbindung mit dem primären DNS-Server (0.0.0.0) über den TCP-Port 53 herstellen. Überprüfen Sie, ob die IP-Adresse des DNS-Servers richtig und der DNS-Server erreichbar ist.

    Warnung:
    Setup kann nicht überprüfen, ob der 'Host' (A)-Datensatz für diesen Computer in der DNS-Datenbank auf Server 0.0.0.0 vorhanden ist.


    Verstrichene Zeit: 00:00:05


    Mailbox-Funktion Voraussetzungen
    Abgeschlossen

    Warnung:
    Setup kann keine Verbindung mit dem primären DNS-Server (0.0.0.0) über den TCP-Port 53 herstellen. Überprüfen Sie, ob die IP-Adresse des DNS-Servers richtig und der DNS-Server erreichbar ist.

    Warnung:
    Setup kann nicht überprüfen, ob der 'Host' (A)-Datensatz für diesen Computer in der DNS-Datenbank auf Server 0.0.0.0 vorhanden ist.


    Verstrichene Zeit: 00:00:06

     

    Montag, 6. Dezember 2010 18:38
  • HI,

    spontan würde ich sagen du postest mal ipconfig /all von dem Rechner.


    Viele Grüße Walter Steinsdorfer MVP Exchange Server http://msmvps.com/blogs/wstein/
    Montag, 6. Dezember 2010 20:02
    Moderator
  • Hallo Walter.

    Schon erledigt. SP3 ist drauf.

    Trotzdem danke.

    Gruss Ingo

    Montag, 6. Dezember 2010 21:11
  • Hi Ingo,

    Warnung:
    Setup kann keine Verbindung mit dem primären DNS-Server (0.0.0.0) über den TCP-Port 53 herstellen. Überprüfen Sie, ob die IP-Adresse des DNS-Servers richtig und der DNS-Server erreichbar ist.

    Exchange fragt bei dem Setup alle auffindbaren DNS-Server an und du wirst in
    einer Schnittstelle 0.0.0.0 als DNS-Server eingetragen haben. Daher auch die
    Frage von Walter zu "ipconfig /all".

    Wenn du sicher bist, dass DNS in allen Bereichen funktioniert, kannst du den
    Fehler einfach ignorieren... wie du es wahrscheinlich gemacht hast.

    Kam es schon zu erneuten Verbindungsabbrüchen und konntest du weiter testen?

    Viele Grüße
    Christian

    Dienstag, 7. Dezember 2010 07:08
    Moderator
  • Hallo Christian.

    Hier werden keine Fehler ignoriert!!!!!!!!

    Nein, habe das Problem gefunden. War natürlich kein falscher DNS 0.0.0.0 eingetragen, sondern der wurde so zusagen gemacht. Im Ex steckt eine weitere NIC für das iSCSI-Netz. Ist total abgetrennt vom Domain Netz. Die Maschinen die mit da dran hängen bekommen ihre IP über DHCP. Da hat sich der Ex wohl auf Grund des fehlenden DNS-Server Eintrags die 0.0.0.0 selbst eingetragen. Habe in den Optionen des DHCP die DNS des Domain Netzes eingetragen und ist weg. Ist zwar für das iSCSI-Netz nicht von Relevanz und auch nicht erreichbar aber die beiden sind zu frieden.

    Gruss Ingo

    Dienstag, 7. Dezember 2010 07:17
  • Hi Ingo,

    Nein SP3 ist noch nicht drauf. Schon versucht, hat aber mit diveresen Fehlermeldungen, allerdings nur Kleinkram, abgebrochen. Hatte aber noch keine Zeit nach dem Problem zu schauen.

    das würde ich auf jeden Fall noch nachholen - es wirkt wie eine
    Neuinstallation, behebt einige Fehler und bringt Verbesserungen...

    Viele Grüße
    Christian


    Wirkt wohl wirklich wie eine Neuinstallation. Wie ich gerade feststellen musste hat der SP so gar unsere eigene OWA-Seite neu gemacht.
    Dienstag, 7. Dezember 2010 07:19
  • Hi Ingo,

    Hier werden keine Fehler ignoriert!!!!!!!!

    War kein Fehler - war ne Warnung! ;-)

    Nein, habe das Problem gefunden. War natürlich kein falscher DNS 0.0.0.0 eingetragen, sondern der wurde so zusagen gemacht. Im Ex steckt eine weitere NIC für das iSCSI-Netz.

    Ja da kam es her...

    Viele Grüße
    Christian

    Dienstag, 7. Dezember 2010 07:29
    Moderator
  • Hi,

    ich glaube das du dir dadurch einen anderen Fehler einfängst sobald versucht wird mit dem Exchange auf der Ip zu sprechen die über da normale Netz nicht zu erreichen ist. Besser ist es die Registrierung im DNS zu unterbinden und eventuelle (falsche) A-Einträge zu löschen.

    Hier der Eintrag der dich zum Ziel führt: http://msmvps.com/blogs/acefekay/archive/2009/08/17/multihomed-dcs-with-dns-rras-and-or-pppoe-adapters.aspx

    In dem Fall ist der Exchange multihomed, soll aber auf der iscsi - Seite ja nicht angesprochen werden.


    Viele Grüße Walter Steinsdorfer MVP Exchange Server http://msmvps.com/blogs/wstein/
    Dienstag, 7. Dezember 2010 08:28
    Moderator
  • Hallo Walter.

    Danke für den Rat. Das ist alles so gemachrt. Der Fehler passierte auf dem Exchange selbst, nicht im DNS.

    Gruss Ingo

    Dienstag, 7. Dezember 2010 08:54
  • Hi,

    ja, der Fehler besagt das Exchange über die falsche Schnittstelle versucht einen DNS zu erreichen. Andersherum könnten auch andere Server versuchen den Exchange auf der falschen IP zu erreichen, deswege der Hinweis.

    Ist denn dein Problem damit erledigt?


    Viele Grüße Walter Steinsdorfer MVP Exchange Server http://msmvps.com/blogs/wstein/
    Dienstag, 7. Dezember 2010 10:20
    Moderator
  • Hallo Walter.

    Nein, wird nicht passieren, weil wie gesagt die Registrierung in der DNS für den Adapter deaktiviert ist und über diese NIC gar keine Verbindung zu den DCs besteht. Gibt auch keine entsprechenden Eintäge in der DNS.

    Der Fehler kam wie beschrieben definitiv von DHCP. Ist jetzt weg und SP3 drauf.

    Trotzdem danke noch mal für den Hinweis.

    Zu dem eigentlichen Problem. Nach einem halben Tag mit SP3 kann man folgendes mit sagen.

    Wo es wohl nur noch Probleme gibt ist auf den TS 2003, mit Outlook 2003 - ja, haben wir noch 3 Stück - die eigentlich "direkt" neben den Exchange stehen. Selber Switch nur andere VLAN.

    An meiner W7 Workstation mit Outlook 2007 über VPN läuft es spürbar zügiger. Wirklich Hänger kann ich nicht bestätigen. Mal 2-4 Sekunden wo es dauert bis man den entsprechenden Ordner im Postfach oder das Postfach bekommt.

    Sollte man die Anpassungen machen wie bei O2003 an E2010?

    Gruss Ingo

    Dienstag, 7. Dezember 2010 13:59
  • So, jetzt hatte ich doch einen Aussetzer. So 3-4 Minuten. Outlook Fenster weiss. Im Verbindungsstatus wechselt es zwischen verbunden und Verbindung wird hergestellt. Als Outlook kam, war das Postfach nicht erreichbar. Als ich auf ein anders Postfach klickte ging das Spiel von vorne los.

    Im Eventlog steht dazu:

    ___________

    Fehlerbucket , Typ 0

    Ereignisname: AppHangTransient

    Antwort: Nicht verfügbar

    CAB-Datei-ID: 0

    Problemsignatur:

    P1: OUTLOOK.EXE

    P2: 12.0.4518.1014

    P3: 4542840f

    P4: unknown

    P5: unknown

    P6: unknown

    P7: unknown

    P8:

    P9:

    P10:

    Angefügte Dateien:

    Diese Dateien befinden sich möglicherweise hier:

     

    Analysesymbol:

    Es wird erneut nach einer Lösung gesucht: 0

    Berichts-ID: f3011bdc-020d-11e0-82b3-001fe2e64eec

    Berichtstatus: 1

    __________

    Und voher schon mal:

    ____________

    Prozess mmc.exe (PID=9612). Fehler bei RPC-Anforderung an den Microsoft Exchange Active Directory-Topologiedienst. Fehler: 1753 (Error 6d9 from HrGetServersForRole). Stellen Sie sicher, dass der Dienst ausgeführt wird.

    ____________

    Der Dienst wird ausgeführt.

    Vielleicht kennt das ja jemand. Ich gehe dann mal googlen.

    Gruss Ingo

    Dienstag, 7. Dezember 2010 14:35
  • Hi,

    mit an Sicherheit grenzender Wahrscheinlichkeit versucht etwas auf die falsche Schnittstelle bei Exchange zuzugreifen, was an deiner IPKonfiguration liegt. Prüf das mal nach. Falls du den Fehler nicht gleich findest: Morgen hätte ich Zeit für eine kurze Remotesession (falls du Vertrauen hast).

     


    Viele Grüße Walter Steinsdorfer MVP Exchange Server http://msmvps.com/blogs/wstein/
    Dienstag, 7. Dezember 2010 16:17
    Moderator
  • Hallo Walter.

    Warum nicht.  Wie kommen wir zusammen?

    Irgendwie verstehe ich es nicht. Was ist an der IP-Konfuguration schlecht.

    Ich kann die iSCSI-NICs testweise auch mal abschalten.

    Gruss Ingo

    Dienstag, 7. Dezember 2010 17:07
  • Hi Ingo,

    Ich kann die iSCSI-NICs testweise auch mal abschalten.

    so richtig weiß ich auch noch nicht, wo es hingeht, denn die Clientauflösung
    klappt und das iSCSI-Netz ist losgelöst vom restlichen LAN.

    ...auf die Ergebnisse bin ich gespant! ;)

    Viele Grüße
    Christian

    Dienstag, 7. Dezember 2010 21:05
    Moderator
  • Hi,

    schick mir eine Mail an wstein@inet-service.com , ich melde mich dann bei dir.


    Viele Grüße Walter Steinsdorfer MVP Exchange Server http://msmvps.com/blogs/wstein/
    Mittwoch, 8. Dezember 2010 00:18
    Moderator
  • Moin,

    wenn Du Dir in der Netzwerkumgebung mal die Reihenfolger der Netzwerkkarten
    ansiehst, ist dann die "normale" zuerst genannt, oder kommt dort die von
    iSCSI zuerst?

    (Netzwerk- und Freigabezenter -> Adaptereinstellungen -> ALT-Taste drücken
    -> Netzwerk -> erweiterte Einstellungen.

    Wichtig ist, dass die Karte mit den korrekten DNS weiter oben steht (oberes
    Auswahlfenster).

    Stand aber auch so im Link von Walter weiter oben drin. :)


    Grüße aus Berlin schickt Robert
    MVP Exchange Server
    Mittwoch, 8. Dezember 2010 07:06
  • Hallo Robert.

    Die Reihenfolge der Netzwerkkarten stimmt auch. Das Problem mit dem falschen DNS-Server ist aber schon gelöst!? Oder beziehst Du das auch auf das eigentliche Problem?

    Gruss Ingo

    Mittwoch, 8. Dezember 2010 08:58
  • Moin,

    Die Reihenfolge der Netzwerkkarten stimmt auch. Das Problem mit dem falschen DNS-Server ist aber schon gelöst!? Oder beziehst Du das auch auf das eigentliche Problem?

    sowohl als auch. Eine falsche Reihenfolge der NW-Karten kann für einige
    merkwürdige Effekte sorgen - und erfahrungsgemäß machen immer die Karten
    Probleme, die eigentlich für das Netzwerk nicht verwendet werden.


    Grüße aus Berlin schickt Robert
    MVP Exchange Server
    Mittwoch, 8. Dezember 2010 10:47
  • Hallo.

    Walter hat sich am Mittwoch die Konfiguration der Exchange mal angeschaut konnte jedoch keinen Fehler finden. Wir haben dann noch ein paar Tests gemacht. Ich gestern auch bei Belastung. Aber auch ohne gravierenden Befund. Die Zugriffszeiten liegen meist im einstelligen ms Bereich. Die trotzdem gemachten Änderungen bisschen mehr RAM und die Protokolle brachten wie erwartet auch keine Besserung.

    Auch Walter vermutet das Problem jetzt nicht mehr beim Exchange. Wenn nicht über HTTPS kommuniziert wird sondern über "TCPIP" dann läuft es ja auch flott. Und beim zweiten Exchange, auf dem fast noch keine User sitzen tritt der Fehler ja auch auf.

    Der Fehler muss also irgendwo im RPC over HTTP liegen. Leider keine Idee wo. Grundsätzlich läuft es ja. Einen Fehler haben wir gefunden. Auf vielen O2003 fehlten SPs. Das ist aber auch inzwischen behoben. Besserung hat es aber auch keine gebracht.

    Aktuell gibt es nur die Möglichkeit wieder auf Mapi zurück zukonfigurieren und das mit HTTPS zu lassen. Die Leute beschweren sich zwar nicht direkt aber so klasse ist das mit den Wartezeiten nicht.

    Gruss Ingo

    Freitag, 10. Dezember 2010 07:53
  • Hi Ingo,

    es ist doch aber so, dass die Clients alle via PRCoverHTTPS über den RD gehen,
    oder?

    Kannst du das bei den internen Clients mal umstellen, sodass sie direkt gehen?
    WebScanEngines vom AV oder Proxy wurde bestimmt auch schon alle deaktiviert?

    Viele Grüße
    Christian

    Freitag, 10. Dezember 2010 08:16
    Moderator
  • Hallo Christian.


    War ja vorher so und werden wir wieder machen, wenn wir das Problem nicht finden. Läuft vollkommen stressfrei.

    Jetzt fragst Du aber was? Ein entsprechender Punkt ist mir in der Verwaltungskonsole noch nicht aufgefallen. Es läuft eine ganz normaler Trend Micro Worry Free Bussiness. Einzig bestimmte Ordner, wie z. B. Hyper-V Verzeichnisse sind vom Scan ausgeklammert.

    Nach x-Test ist jetzt Performance technisch alles im grünen Bereich. Ein Meldung war noch dabei die auf ein Problem hinweisst.

    "Ein einzelner Mapi-Vorgangstyp ist für einen grossen Prozentsatz der Last verantwortlich. RPC-Vorgänge für Mapi-Vorgang "Logon" sind für 50 % der für RPC-Anforderungen reservierten Prozessorlast verantwortlich.

    Im Taskmanager sieht man aber mal gerade gar keine Last.

    Gruss Ingo

     

    Freitag, 10. Dezember 2010 08:54
  • Hallo.

    Also wir schliessen das hier mal. Genug genervt. Ich denke nicht das wir der Sache so auf die Spur kommen. Entweder konfigurieren wir die Clients wieder auf Mapi, oder machen einen Call bei MS auf.

    Danke für Eure Unterstützung. Schade das wir das Problem nicht lösen konnten.

    Gruss Ingo

    • Als Antwort markiert Ingo Schneider Freitag, 10. Dezember 2010 14:55
    Freitag, 10. Dezember 2010 14:55