Outlook mit RPC over HTTPS funktioniert nach Migration nicht

[Dutch_OnE 36]

Hallo Leute,

 

ich habe einen Exchange 2003 nach der Anleitung von Franky Web auf einen anderen Server migriert. Das vorhandene Zertifikat habe ich auf dem neuen Server erfolgreich eingerichtet.

 

Outlook und WebAccess funktionieren einwandfrei. M.M. nach scheint damit auch die richtige Konfiguration vom IIS / Router NAT Port 443 vorhanden zu sein.

 

Was nicht funktioniert ist RPC over HTTPS und die Smartphone Benachrichtigungen.

 

In der Ereignisanzeige stand, dass die User keine Berechtigungen haben RPC zu nutzen. Daraufhin habe ich im AD - Benutzer - Sicherheit - Erweitert den Haken gesetzt, dass die Berechtigungen "duchvererbt" werden sollen.

 

Danach ging es dann auch einen Tag lang. Heute geht wieder nichts mehr (OWA natürlich schon, aber kein RPC)

 

Hat jemand eine Idee, ob ich was vergessen habe?

 

Im Exchange und im IIS ist das offizielle Zertifikat eingebunden. (Es ist von der PSW Group und war für IIS 6 freigegeben) Nun ist IIS7 installiert. Kann es damit was zu tun haben? OWA funktioniert ja auch ...

 

Alles Exchange Updates (SP2 / Ru5) sind installiert.

 

Gruß Daniel

 

 

 

 

[Stefan W 14]

Hi,

steht im Ereignislog erneut etwas drinnen?

 

Welche Fehler werden dir angezeigt, wenn du mit https://www.testexchangeconnectivity.com/ testest?

lg

Stefan

[RobertWi 81]

Moin,

 

hast Du mal die Berechtigungen geprüft, ob die noch so sind?

 

Outlook Anywhere ist auf dem CAS-Server aktiviert worden?

[Dutch_OnE 36]

Outlook Anywhere ist aktiviert. Die Berechtigungen werde ich nochmal überprüfen,aber im Moment ist der Root Server abgestürzt. Der Exchange ist in einer VHD von diesem Server.

[Stefan W 14]

aber im Moment ist der Root Server abgestürzt

 

wir reden hier von einer Testumgebung oder?

[Dutch_OnE 36]

Ja es ist eine Testumgebung.

[Dutch_OnE 36]

Nachdem nun der Exchange 2003 Server entfernt wurde (leider hat die Deinstallation nicht geklappt und ich musste per Hand mit ADSI-Edit nachhelfen) funktioniert ca. 24 Stunden später die Annahmen von externen Mails nicht mehr.

 

Zunächst war die Public Database nicht mehr gemountet. Durch hinzufügen der Ordner Folder Hierachies (und noch 2-3 Einträgen) im ADSI konnte diese wieder eingebunden werden. In der Ereignisanzeige sind nun keine Fehlermeldungen mehr vorhanden.

 

Mails verschicken und interne empfangen funktioniert. Der Empfangsconnector darf von anonym benutzt werden.

Die Speicherkapazität ist ausreichend.

 

Telnet auf den Server mit Port 25 funktioniert intern einwandfrei, aber nicht extern. Wenn ich eine Mail schicke sehe ich das auch im Debug Log des Router. Die Firewall blockt nichts und somit scheint der Server aus welchen Gründen auch immer, extern Port 25 zu verweigern.

 

Mir gehen langsam die Ideen aus. Hat noch jemand eine für mich?

 

Gruß Daniel

[RobertWi 81]

Gibt es denn eine Fehlermeldung? Was steht im SMTP-Protokoll?

[Dutch_OnE 36]

Hallo Robert,

 

ich habe mich gerade mit dem Logging beschäftigt und es erstmal aktiviert.

 

Vorab noch eine Frage:

 

Get-TransportServer | fl name,*log* zeigt mir das TransportSyncLogEnabled auf false steht. Kann ich das ändern?

 

Mit SMTP Protokoll meinst Du (C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\ProtocolLog\SmtpSend bzw. SmtpReceive) ?

 

Dort sehe ich die erfolgreichen Versand- und die internen Empfangsaktivitäten.

 

Die nicht erfolgreichen externen finde ich nicht.

 

[RobertWi 81]

Moin,

 

wenn man mit "Get-XYZ" eine Option ausliest, dann kann man sie i.d.R. mit "Set-XYZ" ändern Oder man ruft sich vorher mal die Hilfe auf, die sagt zu dieser Option:

 

 

    -TransportSyncLogEnabled <$true | $false>

        Der Parameter TransportSyncLogEnabled ist für die interne Verwendung von Microsoft reserviert.

 

Ist also für Dich unwichtig.

 

Ja, dieses SMTP-Protokoll meine ich. Wenn Du die Protokollierung auf ALLEN Empfangs-Connectoren aktiv hast und nichts im Protokoll steht, kommt da auch nichts an.

 

Kann es sein, dass Du auf der Firewall den SMTP-Traffic noch auf den alten Exchange weiterleitest?

[Dutch_OnE 36]

Die Firewall (am Server und am Router) habe ich überprüft. Da kommt auch was an. Was ich gerade noch rausgefunden habe ist ein vorgeschalteter Relay. In einer "Verzögerte Zustellung" Mail steht die Meldung Mailer-Daemon@relayname does not designate permittet sender host.

 

Vermutlich wird dort der Fehler liegen.

 

Eine andere Sache noch: Outlook bringt wieder eine Zertifikatsfehlermeldung. Im Exchange ist eines mit dem internen Mailserver (Dienste: SMTP) und ein offizielles mit externer Adresse (Dienste: IMAP, POP, SMTP, IIS)

 

Wenn ich im Outlook (aus LAN aufgerufen) mir das Zertifikat anschaue, verweist es auf das extrerne. Kann man das irgendwie drehen?

[RobertWi 81]

Hast Du denn überhaupt schon korrekte Zertifikate installiert und die URLs falls notwendig angepasst?

[Dutch_OnE 36]

Im Exchange sind beide vorhanden. Ich habe es dort m.M. nach ordnungsgemäß installiert. Wofür die URLs anpassen und vor allem wo?

Das interne hat die URL mail-server2010 und das externe hat nameowa.de.

 

Outlook meckert beim Starten das der Name auf dem Sicherheitszertifikat ungültig oder stimmt nicht mit dem Namen der Website überein. 

Im IIS ist das externe Zertifikat über HTTPS (Default Web-Site) eingetragen. Alle Unterseiten (RPC, Exchange, ActiveSync, Autodiscover, ...) benötigen SSL. (Meine damit das diese Einstellung aktiviert ist)

[RobertWi 81]

Was meinst Du mit "Im Exchange sind beide vorhanden". Der IIS nutzt immer nur EIN Zertifikat für SSL - mehr geht technisch auf einer IP-Adresse nicht.

 

Stell Dir vor:

- Outlook von intern nutzt für das OAB die URL "https://exchange01.domäne.local/OAB"

- Outlook von extern benutzt für das OAB die URL "https://owa.domäne.de/OAB"

 

Stehen nicht beide Namen im Zertifikat, knallt es.

 

Lösung: Entweder, alle notwendigen URL in Zertifikat nehmen, oder alle URLs so vereinheitlichen, dass eine URL reicht.

 

Das ist aber nichts, was man nebenbei im Forum bearbeiten kann, weil man dazu das Netzwerk analysieren muss, die DNS-Konfig, wieviel Geld vorhanden ist. usw.

 

Das Thema wurde gefühlt schon 1000x im Forum behandelt, zuletzt vor weniger als einen Monat hier: http://www.mcseboard.de/topic/190598-neues-exchange-zertifikat-erstellen-worauf-muss-man-achten/

[Dutch_OnE 36]

In der Exchange Verwaltungskonsole - Serverkonfiguration stehen 2 Zertifikate.

 

Zert1:

DNS-Name=Mail-Server2010

DNS-Name=Mail-Server2010.localdomain.de

 

Zert2:

DNS-Name=externedomain.de

 

Im IIS ist das Zert2 für https eingetragen. Unter Exchange 2003 und Outlook2010 lief es einwandfrei.

Nun ist es Exch2010.

 

Wenn ich das richtig verstanden habe, brauchen wir auf Zert2 noch den DNS Namen von Zert1, damit Outlook ohne Fehlermeldung startet ...