2
Exchange 2013 (Migriert) keine Verbindung mit Outlook
Hallo,
alles erfolgte in einer Testumgebung mit Orginaldaten.
Die Migration erfolgte von einem SBS2003 auf einen Exchange 2010 der auf einem Server 2012 (ohneR2) installiert wurde.
Der 2012 wurde zum DC gemacht AD und Exchange rübergezogen alles perfekt.
Nun erfolgte die Migration von Exchange 2010 auf Exchange 2013SP1 installiert auf einem Server 2012R2.
Soweit so gut.
Die Migration der Daten war erfolgreich (vorher schön alle Sonderzeichen und Leerzeichen aus allen öffentlichen Ordnern/Aliassen entfernen!) und der Zugriff über OWA geht auch super.
Der Exchange 2010 ist deinstalliert.
Was nicht geht ist der Zugriff über Outlook auf den Exchange.
Die interne Domain ist eine .local die Primäre smtp Adresse eine .de Adresse.
Interne URL und Externe URL sind gesetzt
Damit autodiscover richtig geht, wurde für die .local ein SRV Eintrag eingerichtet der auf die Adresse vom Exchange zeigt.
Wenn Outlook neu eingerichtet wird, dann geht alles bis zum anmelden Am Server durch un ddann plopt eine Anmedebox auf.
Egal was dort eingegeben wird, die Haupt, SMTP Adresse, domäne\benutzer, benutzer@domäne.local...
Nichts geht.
Es wird kurz versucht und dann kommt es liegt ein Problem mit dem Sicherheitszertifikat es Proxyservers vor.
Outlook kann keine Verbindung mit dem Proxyserver "Extrne URL" herstellen.
Das Zertifikat wurde mit:
erstellt und dann für IIS, SMTP, IMAP,POP erlaubt und zugeweisen.
Auf dem Client wurde das Zertifikat auch im Computerspeicher für Vertrauenswürdige Zertifizierungsstellen und Herrausgeber aufgenommen.
Der Internetexplorer gibt sogar keine Fehlermeldung beim Aufruf.
Da das Zertifikat als vertrauenswürdig ausgerollt wurde, sollte der Client doch eigendlich nicht meckern.
Irgend etwas muss ich übersehen haben und sehe im Moment den Wald vor lauter Zertifikaten nicht.
Mit einem *.domäne.xx hab ich es auch schon versuht gehabt, mit selben Ergebniss.
Der Kauf eines Zertifikates scheidet aus und würde bei .local ehr nicht gehen.
Die Testserver haben auch keinen Internet zugang, DC, Exchange und Client befinden sich alle an einem eigenen Switch ohne Verbindung nach außen.
Wo könnte ich ansetzen?
Gruß
Chonta
alles erfolgte in einer Testumgebung mit Orginaldaten.
Die Migration erfolgte von einem SBS2003 auf einen Exchange 2010 der auf einem Server 2012 (ohneR2) installiert wurde.
Der 2012 wurde zum DC gemacht AD und Exchange rübergezogen alles perfekt.
Nun erfolgte die Migration von Exchange 2010 auf Exchange 2013SP1 installiert auf einem Server 2012R2.
Soweit so gut.
Die Migration der Daten war erfolgreich (vorher schön alle Sonderzeichen und Leerzeichen aus allen öffentlichen Ordnern/Aliassen entfernen!) und der Zugriff über OWA geht auch super.
Der Exchange 2010 ist deinstalliert.
Was nicht geht ist der Zugriff über Outlook auf den Exchange.
Die interne Domain ist eine .local die Primäre smtp Adresse eine .de Adresse.
Interne URL und Externe URL sind gesetzt
Damit autodiscover richtig geht, wurde für die .local ein SRV Eintrag eingerichtet der auf die Adresse vom Exchange zeigt.
Wenn Outlook neu eingerichtet wird, dann geht alles bis zum anmelden Am Server durch un ddann plopt eine Anmedebox auf.
Egal was dort eingegeben wird, die Haupt, SMTP Adresse, domäne\benutzer, benutzer@domäne.local...
Nichts geht.
Es wird kurz versucht und dann kommt es liegt ein Problem mit dem Sicherheitszertifikat es Proxyservers vor.
Outlook kann keine Verbindung mit dem Proxyserver "Extrne URL" herstellen.
Das Zertifikat wurde mit:
New-ExchangeCertificate -FriendlyName “SelfSigned Certificate” -KeySize 4096 -SubjectName “c=DE, s=, l=, o=Name, ou=IT, cn=domain2.de” -DomainName exchange2013.domain.local, autodiscover.domain.local, webmail.domain2.de, exchange2013, exchange2013.domain.de, autodiscover.domain.de -PrivateKeyExportableerstellt und dann für IIS, SMTP, IMAP,POP erlaubt und zugeweisen.
Auf dem Client wurde das Zertifikat auch im Computerspeicher für Vertrauenswürdige Zertifizierungsstellen und Herrausgeber aufgenommen.
Der Internetexplorer gibt sogar keine Fehlermeldung beim Aufruf.
Da das Zertifikat als vertrauenswürdig ausgerollt wurde, sollte der Client doch eigendlich nicht meckern.
Irgend etwas muss ich übersehen haben und sehe im Moment den Wald vor lauter Zertifikaten nicht.
Mit einem *.domäne.xx hab ich es auch schon versuht gehabt, mit selben Ergebniss.
Der Kauf eines Zertifikates scheidet aus und würde bei .local ehr nicht gehen.
Die Testserver haben auch keinen Internet zugang, DC, Exchange und Client befinden sich alle an einem eigenen Switch ohne Verbindung nach außen.
Wo könnte ich ansetzen?
Gruß
Chonta
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 231873
Url: https://administrator.de/forum/exchange-2013-migriert-keine-verbindung-mit-outlook-231873.html
Ausgedruckt am: 01.04.2025 um 23:04 Uhr
2 Kommentare
Neuester Kommentar
Hallo Chonta,
hast du mal versucht, das Zertifikat bei den Usern in Vertrauenswürdige Zertifikate auszurollen?
Ich hatte mit Exchange 2013 mal ein ähnliches Problem...
Beste Grüße
Berthold
hast du mal versucht, das Zertifikat bei den Usern in Vertrauenswürdige Zertifikate auszurollen?
Ich hatte mit Exchange 2013 mal ein ähnliches Problem...
Beste Grüße
Berthold
Hallo,
danke für den Hinweis, werde es morgen Testen.
Gruß
Chonta
Nachtrag:
Das Zert wurde über GPO auf Domänenebene für Computer ausgerollt.
Beim Client für den Benutzer im Zertifikarstor iportiert, aber nix.
Die Firewall wurde auch so eingestellt, dass port 443 generell frei ist, unabhängig vom Dienst.
Hatte gelesen, das dies auch ein Problem sein kann, aber daran lag es auch nicht.
Gruß
Chonta
Nachtrag: Ok des Rätzels Lösung, warum auch immer der RPC-Clientzugriffsdienst lief einfach nicht..............
danke für den Hinweis, werde es morgen Testen.
Gruß
Chonta
Nachtrag:
Das Zert wurde über GPO auf Domänenebene für Computer ausgerollt.
Beim Client für den Benutzer im Zertifikarstor iportiert, aber nix.
Die Firewall wurde auch so eingestellt, dass port 443 generell frei ist, unabhängig vom Dienst.
Hatte gelesen, das dies auch ein Problem sein kann, aber daran lag es auch nicht.
Gruß
Chonta
Nachtrag: Ok des Rätzels Lösung, warum auch immer der RPC-Clientzugriffsdienst lief einfach nicht..............
