Exchange 2010 - Einzelner Client Problem (Outlook Anywhere / RPC over http)

[PowerShellAdmin 169]

Guten Morgen,

ich habe hier ein etwas verzwicktes Problem mit einem Client und mich würde interessieren ob ihr noch eine Idee habt.

 

Wir haben einen Exchange 2010 im Einsatz  - Der Zugriff über Outlook 2016, 2010, 2013 intern, als auch außerhalb über Outlook Anywhere läuft allgemein ohne Probleme.

 

Exchange: Windows 2008r2 (aktuelle Updates), Exchange 2010 - SP3 - RU11

Client: Windows 7 x64, Office 2016 (aktuelle Updates), ESET NOD32, kein Mitglied der Domäne

 

 

Problem: Ein einzelner externer Client braucht Minuten bis zum Verbindungsaufbau über Outlook Anywhere (aktiviere ich die VPN am betroffene Client, wird sofort verbunden).

 

Lösungsansetze:

-Kennwörter aus dem Passworttresor von Windows gelöscht

-Edit: Outlook-Profile gelöscht und Outlook Settings

-Das Problem bestand bereits mit Outlook 2010 auf diesem Client, 2013 oder 2016 haben keine Besserung gebracht

-Autodiscover Einstellungen werden von Outlook 2016 ohne Probleme erkannt (Verbindungsaufbau erfolgt ja auch erfolgreich - aber er braucht halt..)

-Testweise Registrierungseintrag gesetzt (http://www.haveyourebooted.com/outlook-2016-autodiscover-slow-with-hosted-exchange/)

 

Hinweis:

Wie oben bereits steht - Autodiscover funktioniert ohne Probleme. Habe selbst Windows 10 mit ESET und Outlook 2010 - 2016 dort im Einsatz und das Problem ist ein absoluter Einzelfall.

bearbeitet 16. März 2016 von PowerShellAdmin

[Nobbyaushb 1.471]

Moin,

 

da hast du ja schon einiges versucht.

 

Was ist denn bei diesem Client anders als bei den anderen?

 

Was für eine Internetverbindung hat der, spuckt dir dort irgendeine Einstellung seitens des Providers ins Hemd?

 

Traceroute etc vom Client läuft sauber durch?

 

Ggf. hohe Latenzen, LTE oder UMTS?

 

;)

[PowerShellAdmin 169]

Moin Nobbyaushb,

auf dem Client lief in der Vergangenheit O2007 und das System ist länger im Betrieb.

Ist ein Buchhaltungsrechner - daher laufen hier doch diverse weitere Programme (welche aber nicht direkt mit Outlook Anywhere kollidieren sollten).

 

Provider:

-Am Standort ein einfacher Telekom Business Anschluss (VDSL 50). Probleme sind hier nicht bekannt und aufällig geworden.

-Die Verkabelung zum Gateway/Router ist Gigabit

 

Mit RPCDiag fällt auf, dass der Verbindungsaufbau sehr, sehr lange dauert.

 

@Traceroute von was ? Zur IP des Exchange-Servers ?

bearbeitet 16. März 2016 von PowerShellAdmin

[testperson 1.680]

Hi,

 

bin mir nicht sicher, ob die Telekom das in Business Verträgen auch macht. Aber bei privat Anschlüssen hatten wir schon häufig das Problem mit der "Navigationshilfe" der Telekom (https://social.technet.microsoft.com/Forums/de-DE/41e3adec-cca3-4f45-bda8-58426fc76408/outlook-anywhere-funktioniert-nicht-an-bestimmten-dslanschlssen?forum=exchange_serverde / http://www.msxfaq.de/exchange/clients/oadebug.htm).

 

Gruß

Jan

[PowerShellAdmin 169]

Danke das wäre ja ein Anhalspunkt.

Teste es an dem Standort heute Abend über einen weiteren Client um dies auszuschließen.

 

Tolles Stück natürlich in Outlook 2016

"(2) bei der RPC Proxy Konfiguration nur den Punkt "Bei langsamen Verbindungen zuerst per HTTP und dann per TCP/IP verbinden" auswählst" => ehm ja... ;)

 

-Hatte die Navigationshilfe der T-Com testweise deaktiviert => keine Besserung.

bearbeitet 16. März 2016 von PowerShellAdmin

[PowerShellAdmin 169]

so ein kleines Update, es lag tatsächlich an der Telekom.

hatte das Feature deaktiviert und Router neugestartet, DNS Cache geleert, aber scheinbar hat das etwas mehr Zeit benötigt...

 

NSLookUp auf die interne IP Adresse des Exchange CAS => keine Auflösung (also so korrekt). Davor gab es eine IP zurück.

Outlook schnurrt wieder :)

 

Danke für die Unterstützung !

[testperson 1.680]

Hi,

 

beobachte das aber mal. Bei mir zu Hause hatte ich die Navigationshilfe ausgeschaltet (Steht immer noch auf deaktiviert) und habe den Router schon mehrfach neu gestartet. Leider pfuscht die Navigationshilfe immer noch dazwischen. Hab dann am Router einfach die DNS auf die von Google konfiguriert. Seit dem ist Ruhe ;)

 

Gruß

Jan

[PowerShellAdmin 169]

Und schön die Daten nach Amerika  :-O

 

Auf MSXFAQ.de stand der Ansatz noch folgender Ansatz:

"Es dauert einige Timeouts, bis Outlook aufgibt und dann doch RPC/HTTP macht. Leider scheint die Telekom diesen "Service" per Default für alle Kunden aktiviert zu haben und muss von jedem Anschlussinhaber individuell im Kundencenter abgeschaltet werden. Es könnte also ein Workaround sein, den CASARRAY-Namen im Internet zu pflegen und auf eine IP-Adresse zu lenken, die auf den Verbindungsversuch 135/TCP schnell mit einem "RESET" antwortet."

 

Das wird natürlich wieder schwierig - beim TLD Local wird das ganze sehr problematisch und schwer lösbar.

Außerdem wirklich eine Bastellösung.

 

Wieder so eine Umsetzung, die konzeptfremd ist.. hauptsache noch weitere Werbeeinnahmen....

bearbeitet 17. März 2016 von PowerShellAdmin

[NorbertFe 2.035]

Und schön die Daten nach Amerika  :-O

 

Auf MSXFAQ.de stand der Ansatz noch folgender Ansatz:

"Es dauert einige Timeouts, bis Outlook aufgibt und dann doch RPC/HTTP macht. Leider scheint die Telekom diesen "Service" per Default für alle Kunden aktiviert zu haben und muss von jedem Anschlussinhaber individuell im Kundencenter abgeschaltet werden. Es könnte also ein Workaround sein, den CASARRAY-Namen im Internet zu pflegen und auf eine IP-Adresse zu lenken, die auf den Verbindungsversuch 135/TCP schnell mit einem "RESET" antwortet."

 

Das wird natürlich wieder schwierig - beim TLD Local wird das ganze sehr problematisch und schwer lösbar.

Außerdem wirklich eine Bastellösung.

 

Wieder so eine Umsetzung, die konzeptfremd ist.. hauptsache noch weitere Werbeeinnahmen....

Dafür gibt's Split-DNS für Exchange. ;)