SBS 2011 Outlook Anywhere funktioniert nicht

[manuel1985 11]

Hi,

 

Habe eine Testumgebung bestehend aus SBS 2011 auf einem ProLiant ML350 G6 mit Server 2012 und Hyper-V.

Das Netzwerk besteht aus Cisco Small Business 520W an einer Cisco Small Business 520 am Internet.

 

Ziel der Umgebung ist eine Migration vom Exchange 2010 zu Office 365.

 

www.testexchangeconnectivity.com zeigt beim Test der Outlook Anywhere-Funktion das Bild im Anhang. Die Ports sind auf beiden SAs freigeschaltet, OWA und Remote Web Access funktionieren.

unsere Test-Domain ist auf einen no-ip.biz-Eintrag weitergeleitet, ein MX-Record für die Test-Domain ist gesetzt, Mails können versendet und empfangen werden.

Spaßeshalber habe ich die SBS-Firewall mal ausgeschaltet, keine Änderung.

Mit den Kollegen habe ich mich bereits besprochen, theoretisch müsste alles funktionieren (dem ist aber nicht so! Verdammt!).

 

Frage an euch Kollegen an dieser Stelle:
Wer hat noch Ideen und kann mir weiterhelfen?

So lange das ganze nicht grün ist, kann ich nicht migrieren :)

bearbeitet 27. Juni 2013 von manuel1985

[RobertWi 81]

Moin,

 

da ist scheinbar ein Fehler im DNS. Da Du die Domänen-Namen verschleierst, können wir leider nicht selbst nachschauen.

[manuel1985 11]

Nun, da es sich hier um eine Test-Domain und eine Testumgebung handelt, sollte es kein Problem sein, euch alles zu zeigen :)
Bild habe ich so gerade aktualisiert.

[RobertWi 81]

Moin,

 

ich meine vorhin einen anderen Fehler gesehen zu haben.

 

Der jetzige ist:

 

Keine Verbindung auf https://also-test.de ist möglich. Kann ich nachvollziehen, geht mit meinem Browser nicht. Auch OWA geht darüber nicht.

 

Und eine "Weiterleitung" (was soll das genau sein?) finde ich im DNS auch nicht. also-test.de zeigt auf den A-Eintrag "62.116.130.8" (InterNetX GmbH). Der MX Eintrag dagegen zeigt wirklich auf einen "no-ip"-Eintrag.

 

Also ein Problem im DNS oder in der Firewall.

[manuel1985 11]

Meine Testumgebung hat keine feste IP, daher der no-ip-Dienst. Unsere IT hat die Domain registriert und entsprechend im DNS eine Weiterleitung auf die no-ip-Adresse eingerichtet. Hat gestern noch funktioniert.

OK, erste Aufgabe: die sollen den A-Eintrag prüfen. Der Ping auf die no-ip-Adresse gibt die IP 91.16.201.7 aus. Passt ja also schonmal nicht.

So, IT sagt, das hat alles so seine Richtigkeit. Die InterNetX GmbH-Adresse ist ein Weiterleitungsserver. Da passiert nicht mehr als die Weiterleitung der also-test.de auf also-test.no-ip.biz.

 

 

Ich habe mir nochmal in Ruhe ein paar Gedanken gemacht und festgestellt, dass ich den IIS via https-Verbindung nicht erreiche:

 

https://also-test.de -> passiert nichts

http://also-test.de -> IIS Startseite erscheint

 

 

Via Google bin ich noch auf das Thema Zertifikate gestoßen. OWA poppt zwei Meldungen auf:

1. via also-test.no-ip.biz/owa kommt die Standard-IE-Meldung, Webseite schließen oder fortsetzen

2. via also-test.de/owa kommt die Meldung "Der Inhalt wurde geblockt, da er nicht mit einem gültigen Sicherheitszertifikat signiert wurde."

 

Ich tippe, dass das auch etwas mit meinem Problem zu tun hat und ich vermutlich irgendein Zertifikat irgendwo importieren muss, oder? Wenn ja, welches und wo?

[RobertWi 81]

Moin,

 

nur Browser sind in der Lage, eine HTTP oder Header-Weiterleitung auszuwerten. Kein anderer Client (Outlook, EAS, etc.) kann das.

 

Die IP-Adresse MUSS auf Deinen Host zeigen. as einzige, was geht, ist ein CNAME. Andere Spielereien funktionieren.

 

Das Zertifikat kommt dann erst danach, zuerst die Namensauflösung richtig machen.

[manuel1985 11]

Guten Morgen,

 

OK, kapiert. Habe die Infos gestern noch an meinen Kollegen weitergegeben. Sobald ich eine Rückmeldung habe, berichte ich wieder.

 

Edit: Mal zur Info für mich - wie bewerkstelligt man in meinem Fall die Umleitung von also-test.de auf meinen Server? Der Server hängt ja an einer dynamischen IP, somit müsste ich doch jeden Tag die Umleitung im DNS anpassen? Oder gibt es da andere Lösungen? Wäre das in dem Fall der CNAME?

Unsere IT hat nun einen CNAME eingerichtet: exchange.also-test.de

bearbeitet 28. Juni 2013 von manuel1985

[RobertWi 81]

Moin,

 

ja, das würde man mit einem CNAME lösen.

 

Der von der IT eingerichtet nützt Dir nichts, weil Exchange den nicht nutzt. Du musst jetzt noch einen SRV-Eintrag für Autodiscover setzen lassen und die externen URLs auf den verschiedenen virtuellen Verzeichnissen ändern.

[manuel1985 11]

Also statt exchange.also-test.de autodiscover.also-test.de oder zusätzlich?

 

Das ganze wäre mit fester IP vermutlich 1000x einfacher, oder?

[NorbertFe 1.827]

Eigentlich nicht, da man eben überall nur mit A-Records, SRV-Records arbeitet. Allerdings ist es immer etwas schwieriger nachzuvollziehen, da eben Namenstechnisch immer ein DYNDNS-Provider dazwischen hängt. ;) Grad wenn man nicht sattelfest in Exchange und DNS ist, erschwert das die Sache etwas. Technisch ist es aber IMHO identisch.

 

Bye

Norbert

[RobertWi 81]

Das ganze ist zu kompliziert, um es in einem Forum zu erklären, da es immer mehrere Lösungen gibt.

 

Du kannst DNS anpassen (in gewissen Grenzen) und musst Exchange anpassen.

 

Wie Norbert schreibt: Technisch ist eine feste Adresse nicht erforderlich.

[manuel1985 11]

OK. Werde mich in der Hinsicht mal mit DNS beschäftigen (müssen). Bisher war das Wissen so nicht vorhanden.

 

Die IT richtet mir einen CNAME autodiscover.also-test.de ein.

Im Exchange ändere ich jetzt die Autodiscover-Adresse wie folgt:

 

set-AutodiscoverVirtualDirectory
- InternalUrl https://autodiscover.also-test.de/Autodiscover/Autodiscover.xml
- ExternalUrl https://autodiscover.also-test.de/Autodiscover/Autodiscover.xml

[RobertWi 81]

Nein, diese Änderung sind eh wirkungslos, weil die Exchange gar nicht auswertet.

 

Wenn Deine IT die Adresse so ändert, geht Autodiscover von alleine.

 

Und Outlook Anywhere dürfte dann auch nicht gehen, dass muss wie auch die URLS für OAB und EWS noch angepasst werden. Und dann sollten noch die URLs von OWA, ECP und EAS korrigiert werden, die braucht aber Outlook nicht.

 

Allerdings wirst Du dann wahrscheinlich Zertifikatsfehler haben....

[manuel1985 11]

Für OWA, ECP, etc. ist im Server (durch den Assistenten) remote.also-test.de eingetragen. Also, weiteren CNAME, damit das funktioniert und das Zertifikat vom Server exportieren und am Client importieren, richtig?

[RobertWi 81]

Für OWA, ECP, etc. ist im Server (durch den Assistenten) remote.also-test.de eingetragen. Also, weiteren CNAME, damit das funktioniert

 

Ja.

 

und das Zertifikat vom Server exportieren und am Client importieren, richtig?

 

Diese Lösuing ist unspported und sollte nur für das Testen benutzt werden