12
Exchange 2010 - Split DNS - Zertifikatswarnung
Hallo,
ich habe hier einen Exchange 2010 Server im Einsatz.
Das Zertifikat war zum Erneuern fällig. Da interne Domains nicht mehr in das Zertifikat mit aufgenommen werden können, habe ich Split-DNS konfiguriert und die Exchange Dienste laut Anleitung (Microsoft) umkonfiguriert (ECP, EAS, OABD, OWA, Autodiscover, WebServicesVirtualDirectory). Split-DNS funktioniert.
Nach dem Einspielen des neuen Zertifikates kommt es im Outlook dennoch zu einem Zertifikatsfehler.
Über "E-Mail Autokonfiguration testen" zeigt er mir unter Server immer noch den internen Domainnamen an.
Muss ich hier die E-Mail Konten mit dem externen Servernamen neu einrichten?
Oder was könnte das Problem sein?
VG Marko
ich habe hier einen Exchange 2010 Server im Einsatz.
Das Zertifikat war zum Erneuern fällig. Da interne Domains nicht mehr in das Zertifikat mit aufgenommen werden können, habe ich Split-DNS konfiguriert und die Exchange Dienste laut Anleitung (Microsoft) umkonfiguriert (ECP, EAS, OABD, OWA, Autodiscover, WebServicesVirtualDirectory). Split-DNS funktioniert.
Nach dem Einspielen des neuen Zertifikates kommt es im Outlook dennoch zu einem Zertifikatsfehler.
Über "E-Mail Autokonfiguration testen" zeigt er mir unter Server immer noch den internen Domainnamen an.
Muss ich hier die E-Mail Konten mit dem externen Servernamen neu einrichten?
Oder was könnte das Problem sein?
VG Marko
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 262380
Url: https://administrator.de/contentid/262380
Ausgedruckt am: 26.11.2024 um 02:11 Uhr
12 Kommentare
Neuester Kommentar
Habe es getestet. Auch ein Neueinrichten des E-Mail Kontos im Outlook bringt nicht die Lösung. Auch wenn ich den ext. FQDN angebe, wechselt er automatisch zum internen FQDN.
VG Marko
VG Marko
Hi,
Und - wie ist der Exch denn von extern erreichbar? Über einen TMG?
E.
Da interne Domains nicht mehr in das Zertifikat mit aufgenommen werden können,
Wer sagt denn sowas?Und - wie ist der Exch denn von extern erreichbar? Über einen TMG?
E.
Interne FQDN (z.B. *.local) können nicht mehr in UCC Zertifikate mit aufgenommen werden.
Wurde mir auch von unserem Zertifikatsanbieter so bestätigt.
Von extern funktioniert alles. Es geht um die interne Anbindung der Outlook Clients. Da greift er immer noch auf den FQDN "server.domain.local" zu, anstatt auf den öffentlichen FQDN.
VG Marko
Wurde mir auch von unserem Zertifikatsanbieter so bestätigt.
Von extern funktioniert alles. Es geht um die interne Anbindung der Outlook Clients. Da greift er immer noch auf den FQDN "server.domain.local" zu, anstatt auf den öffentlichen FQDN.
VG Marko
Hallo Marko,
hast du mal den Service Connection Point (SCP) im AD überprüft.
Active Directory Standorte und Dienste starten, dann unter Ansicht Dienstknoten anzeigen aktivieren und hierhin navigieren:
http://theucguy.net/service-connection-point-scp-in/
Und zweitens, habt Ihr einen SRV-Eintrag für Autodiscover in eurem DNS der vielleicht auf den internen Namen zeigt ? Wenn nicht kannst du diesen zusätzlich mal anlegen:
http://stephan-mey.de/autodiscovery-dns-eintrag-srv-erstellen/
Grüße Uwe
hast du mal den Service Connection Point (SCP) im AD überprüft.
Active Directory Standorte und Dienste starten, dann unter Ansicht Dienstknoten anzeigen aktivieren und hierhin navigieren:
http://theucguy.net/service-connection-point-scp-in/
Und zweitens, habt Ihr einen SRV-Eintrag für Autodiscover in eurem DNS der vielleicht auf den internen Namen zeigt ? Wenn nicht kannst du diesen zusätzlich mal anlegen:
http://stephan-mey.de/autodiscovery-dns-eintrag-srv-erstellen/
Grüße Uwe
Hallo Uwe,
den SCP habe ich überprüft. Der Eintrag "serviceBindingInformation" zeigt auf die richtige externe Domäne.
SVR-Eintrag habe ich angelegt. Leider auch ohne Erfolg.
Wenn ich mit Outlook die "E-Mail Autokonfiguration" teste, zeigt er unter Server immer den lokalen FQDN an.
Hier noch mal ein Screenshot. Vielleicht stimmt da was nicht. Muss der Eintrag bei FQDN auf dem lokalen oder externen zeigen?
den SCP habe ich überprüft. Der Eintrag "serviceBindingInformation" zeigt auf die richtige externe Domäne.
SVR-Eintrag habe ich angelegt. Leider auch ohne Erfolg.
Wenn ich mit Outlook die "E-Mail Autokonfiguration" teste, zeigt er unter Server immer den lokalen FQDN an.
Hier noch mal ein Screenshot. Vielleicht stimmt da was nicht. Muss der Eintrag bei FQDN auf dem lokalen oder externen zeigen?
Zitat von @EinsteinJunior:
Hier noch mal ein Screenshot. Vielleicht stimmt da was nicht. Muss der Eintrag bei FQDN auf dem lokalen oder externen zeigen?
Das ist OK so.Hier noch mal ein Screenshot. Vielleicht stimmt da was nicht. Muss der Eintrag bei FQDN auf dem lokalen oder externen zeigen?
Manchmal benötigt es etwas Zeit für die Replikation der Einstellung, ein Reboot sollte das beschleunigen.
Sind Outlook Anywhere URLs konfiguriert ?
Powershell: Konfigurieren der internen und externen URLs von Exchange Server 2013, 2016
Existiert ein DNS Eintrag ala autodiscover.domain.de ?
Outlook Anywhere ist bei uns nicht aktiviert. Müssen die URLs trotzdem konfiguriert werden?
DNS-Eintrag autodiscover.xxxxx.de existiert. nslookup und ping zeigen auf die korrekte interne IP-Adresse.
Habe zwar sämtliche IIS- und Exchange-Dienste bereits neu gestartet, werde aber heute Abend den Server mal komplett neu starten.
Hoffe das bringt was.
VG Marko
DNS-Eintrag autodiscover.xxxxx.de existiert. nslookup und ping zeigen auf die korrekte interne IP-Adresse.
Habe zwar sämtliche IIS- und Exchange-Dienste bereits neu gestartet, werde aber heute Abend den Server mal komplett neu starten.
Hoffe das bringt was.
VG Marko
Müssen die URLs trotzdem konfiguriert werden?
Nur wenn Outlook von extern über RPC o. HTTPs genutzt wird.Checke mal die RPCClientAccessServer Eigenschaft der Datenbank:
http://anandthearchitect.com/2013/03/25/exchange-server-2010-whats-your ...
http://community.spiceworks.com/topic/331203-exchange-2010-autodiscover ...
Ich glaube du bist auf dem richtigen Weg.
Hier steht noch die interne FQDN drinnen. Leider lässt er mir es aber auf die externe Domain nicht ändern.
ping und nslookup funktionieren auf die externe Domain.
Hier steht noch die interne FQDN drinnen. Leider lässt er mir es aber auf die externe Domain nicht ändern.
ping und nslookup funktionieren auf die externe Domain.
Hallo Uwe,
dein Tipp hat mich schon ein wenig weiter gebracht. Ich war anscheinend gestern geistig schon im Nirvana und hatte vergessen das "CAS Array" anzulegen.
Unter Server wird jetzt die externe Domain (im Outlook) angezeigt. Das passt. Leider bringt Outlook beim Start immer noch eine Zertifikatswarnung mit der internen FQDN.
Unter Verbindungsstatus ist im Outlook nur noch der externe Domainname zu sehen. Keine Ahnung wo er immer noch auf den internen Namen zugreift.
Vielleicht hat noch jemand einen Tipp.
VG Marko
dein Tipp hat mich schon ein wenig weiter gebracht. Ich war anscheinend gestern geistig schon im Nirvana und hatte vergessen das "CAS Array" anzulegen.
Unter Server wird jetzt die externe Domain (im Outlook) angezeigt. Das passt. Leider bringt Outlook beim Start immer noch eine Zertifikatswarnung mit der internen FQDN.
Unter Verbindungsstatus ist im Outlook nur noch der externe Domainname zu sehen. Keine Ahnung wo er immer noch auf den internen Namen zugreift.
Vielleicht hat noch jemand einen Tipp.
VG Marko
Hallo Marko,
Outlook speichert den RPCEndpoint im Profil zwischen. Du musst am besten das Profil komplett löschen und neu erstellen:
Quelle: https://technet.microsoft.com/en-us/magazine/ff626260.aspx
Noch mehr Futter dazu gibt's hier:
http://www.shudnow.net/2010/04/18/creating-databases-and-the-rpcclienta ...
Grüße Uwe
Outlook speichert den RPCEndpoint im Profil zwischen. Du musst am besten das Profil komplett löschen und neu erstellen:
The Outlook client (whether Outlook 2003, 2007 or 2010) won’t pick up the change automatically. If you use Outlook 2007 or 2010, you can have the profile updated by making the old RPC endpoint unavailable or by performing profile repair. But Outlook 2003 can’t change the endpoint and doesn’t include a profile repair feature. That forces you to go in and manually change the profile by removing the username, adding it back and then clicking the “Check name” button). This isn’t ideal by itself, and it also involves end users, so you really should create the CAS array beforehand.
Noch mehr Futter dazu gibt's hier:
http://www.shudnow.net/2010/04/18/creating-databases-and-the-rpcclienta ...
Grüße Uwe
Hallo Uwe,
vielen Dank für die Hilfe.
Bei Outook 2013 war die finale Lösung noch das Profil zu löschen und neu anzulegen.
Jetzt funktioniert es so wie es soll.
VG Marko
vielen Dank für die Hilfe.
Bei Outook 2013 war die finale Lösung noch das Profil zu löschen und neu anzulegen.
Jetzt funktioniert es so wie es soll.
VG Marko
