Outlook Anywhere

  • Hi,


    Meine XP Clients haben zwei mögliche Routen die zu unserem Exchange Server führen. Einmal über die VPN Tunnel und einmal über WAN (Outlook Anywhere).


    Hier mal eine Zeichnung um das ganze zu verdeutlichen:


    [Blockierte Grafik: http://www.abload.de/img/paintingvopt.png]


    Ich MUSS den XP Client in der Zeichnung dazu bringen, das er NICHT über das VPN zum Exchange Server verbindet. Ich kämpfe jetzt seit 4 Tagen damit, und es will mir einfach nicht gelingen!


    Outlook Anywhere ist konfiguriert und funktioniert mit externen Clients Wunderbar. Die internen Clients verbinden zwar auch über RPC over HTTPS aber eben über die VPN route.


    Ich bin für jede Hilfe dankbar!


    Gruß
    Sebastian

    • Offizieller Beitrag

    Moin,


    Zitat


    Ich MUSS den XP Client in der Zeichnung dazu bringen, das er NICHT über das VPN zum Exchange Server verbindet. Ich kämpfe jetzt seit 4 Tagen damit, und es will mir einfach nicht gelingen!


    Outlook Anywhere ist konfiguriert und funktioniert mit externen Clients Wunderbar. Die internen Clients verbinden zwar auch über RPC over HTTPS aber eben über die VPN route.


    Über welchen DNS-Namen verbinden sich denn die internen Clients? Mit dem externen?


    Ich sehe hier nur zwei Ansatzmöglichkeiten, wenn nicht die Clients geändert werden sollen.


    - Der VPN-Router blockt den RPC-Port (135).
    - DNS liefert bei VPN die korrekte externe IP-Adresse


    Eventuell brauchst Du auch das hier: http://en.wikipedia.org/wiki/Split-horizon_DNS

  • Inzwischen scheint es gelöst!


    Ich Blödmann hatte während der ganzen Tests einen Split_DNS Eintrag für mail.mydomain.com gelegt der auf die LAN IP zeigte. Und dann vergessen ihn wieder raus zu nehmen. Ich könnte, hinter meinem Computer her, aus dem Fenster springen!


    Es reicht offenbar aus mit folgendem Eintrag:


    Set-OutlookProvider EXPR -OutlookProviderFlags:ServerExclusiveConnect


    HTTPS over RPC zu erzwingen. Damit wird "Bei schnellen Netzwerken zuerst eine Verbindung über HTTP herstellen, dann über TCP/IP" gesetzt. Und damit kommt es zu dem gewünschten verhalten.

    • Offizieller Beitrag

    Moin,


    nicht ganz. HTTP reagiert prinzipbedingt langsamer als RPC.


    Wenn Outlook nun nach HTTP sucht und der antwortet nicht schnell genug, probiert Outlook RPC auf. Wenn der dann antwortet (i.d.R. schneller als HTTP), dann nimmt Outlook kein HTTP mehr, sondern nur noch RPC.


    Wenn Du das verlässlich haben willst, musst Du also den RPC-Zugriff über VPN unterbinden - Firewall oder DNS.


    Probiere es aus: Schalte den IIS aus und starte Outlook. Wenn er sich dann *nicht* bei RPC verbindet (sondern gar nicht), dann hast Du die Lösung. Wenn er nach einigen Augenblicken RPC macht, musst Du RPC über VPN noch unterbinden.

  • Hallo Robert,


    Was du sagst klingt sehr Interessant. Ich hoffe das http dann nicht zum Spassbremser wird.


    Ich denke aber ich werde es so lassen. Sowohl VPN als auch die externe Route sind lediglich ADSL2 Leitungen. Wenn die eine mal nicht mehr will, dann ist es nicht schlecht wenn noch das fallback auf TCP ueber VPN da ist.


    Wie schaetzt du das ganze performance maessig ein, ich habe 10 bis 25 User die gleichzeitig ihre E-Mails ueber den WAN link (1MBit upload) per OA nutzen werden. Reicht die Leitung dafuer?


    Gruss
    Sebastian