Zertifikats-Fehlermeldung bei Outlook in Verbindung mit Exchange 2016
Hallo Zusammen,
erstmal noch ein gesundes neues Jahr
Ich bin gerade dabei von einem Exchange 2010 auf Exchange 2016 zu migrieren (ein erstes Testpostfach konnte ich auch bereits erfolgreich umziehen).
Der Zugriff über OWA (externe URL) im internen Netz (https://outlook.ads-xx.de/owa) funktioniert auch (entsprechender DNS-Eintrag, der auf die lokale IP 172.22.16.105 vom Exchange verweist ist vorhanden, funktioniert auch.)
Für die externe-URL (die ja auch intern erreichbar ist), habe ich ein entsprechendes DV-SSL-Zertifikat gekauft und eingebunden, das funktioniert auch.
Leider habe ich trotzdem das nervige Zertifikats-Problem:
Wenn ich auf "Zertifikat anzeigen.." klicke, bekomme ich das SSL-Zertifikat für meine externe URL angezeigt, was aber trotzdem als "nicht Vertrauenswürdig" erscheint, weil Outlook den Server unter dem lokalen Namen "fo1vmsrm05.ads.local" anspricht.
Die Frage an Euch wäre jetzt, kann ich den Namen mit dem Outlook den Exchange anspricht irgendwo ändern oder habt ihr vielleicht eine andere Lösungsmöglichkeit für mich?
Diesen Fehler hatte ich bereits mit Exchange 2010 (und Outlook 2010), aber wenn wir jetzt schon auf Windows 10 und Office 2016 migrieren, wäre es schön, wenn ich den Fehler nicht "mit-migriere"
Danke vorab!
erstmal noch ein gesundes neues Jahr
Ich bin gerade dabei von einem Exchange 2010 auf Exchange 2016 zu migrieren (ein erstes Testpostfach konnte ich auch bereits erfolgreich umziehen).
Der Zugriff über OWA (externe URL) im internen Netz (https://outlook.ads-xx.de/owa) funktioniert auch (entsprechender DNS-Eintrag, der auf die lokale IP 172.22.16.105 vom Exchange verweist ist vorhanden, funktioniert auch.)
Für die externe-URL (die ja auch intern erreichbar ist), habe ich ein entsprechendes DV-SSL-Zertifikat gekauft und eingebunden, das funktioniert auch.
Leider habe ich trotzdem das nervige Zertifikats-Problem:
Wenn ich auf "Zertifikat anzeigen.." klicke, bekomme ich das SSL-Zertifikat für meine externe URL angezeigt, was aber trotzdem als "nicht Vertrauenswürdig" erscheint, weil Outlook den Server unter dem lokalen Namen "fo1vmsrm05.ads.local" anspricht.
Die Frage an Euch wäre jetzt, kann ich den Namen mit dem Outlook den Exchange anspricht irgendwo ändern oder habt ihr vielleicht eine andere Lösungsmöglichkeit für mich?
Diesen Fehler hatte ich bereits mit Exchange 2010 (und Outlook 2010), aber wenn wir jetzt schon auf Windows 10 und Office 2016 migrieren, wäre es schön, wenn ich den Fehler nicht "mit-migriere"
Danke vorab!
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 530637
Url: https://administrator.de/contentid/530637
Ausgedruckt am: 08.11.2024 um 00:11 Uhr
34 Kommentare
Neuester Kommentar
Hallo,
dann stelle doch die internen URIs auf die externen Adressen ein und passe das Autodiscover entsprechend an?!?
Gruß,
Jörg
dann stelle doch die internen URIs auf die externen Adressen ein und passe das Autodiscover entsprechend an?!?
Gruß,
Jörg
Hi,
was heißt bei dir, es ist so umgesetzt?
- Sind die Zonen im AD mit dem Host Eintrag erstellt?
- Sind alle dazugehörigen Dienste im Exchange auf die URL angepasst?
Autodiscover getestet?
Oben im Screenshot ist zu sehen, dass noch beide Server in der ECP Konsole vorhanden sind.
Die Migration ist also noch nicht abgeschlossen. Du verbindest dich auf den korrekten Server?
Die URLs sind überall angepasst?
Lasse dir doch mal die URLs per Powershell ausgeben, ob dort alles passt.
Grüße Phil
was heißt bei dir, es ist so umgesetzt?
- Sind die Zonen im AD mit dem Host Eintrag erstellt?
- Sind alle dazugehörigen Dienste im Exchange auf die URL angepasst?
Autodiscover getestet?
Oben im Screenshot ist zu sehen, dass noch beide Server in der ECP Konsole vorhanden sind.
Die Migration ist also noch nicht abgeschlossen. Du verbindest dich auf den korrekten Server?
Die URLs sind überall angepasst?
Lasse dir doch mal die URLs per Powershell ausgeben, ob dort alles passt.
Grüße Phil
Hallo,
ja - das Autodiscover musst Du zwingend ändern. Afaik geht das auch gar nicht mehr ohne.
Gruß,
Jörg
ja - das Autodiscover musst Du zwingend ändern. Afaik geht das auch gar nicht mehr ohne.
Gruß,
Jörg
Moin Frank,
hast du dir mal dir URLs per Powershell ausgeben lassen?
Hast du dir urls per Weboberfläche oder per Powershell angepasst?
Blöde Frage, aber die Exchange Server mal durchgestartet?
Kannst du mal ein zweites Postfach migrieren oder ein Testpostfach anlegen und migrieren?
Der servername welcher im Zertifikat angemeckert wird ist der Exchange 2016 oder der alte?
Nicht das er eine Verbindunf zu z. B. Public Folder Database auf dem 2010 herstellen will, aber nicht kann?
Grüße Phil
hast du dir mal dir URLs per Powershell ausgeben lassen?
Hast du dir urls per Weboberfläche oder per Powershell angepasst?
Blöde Frage, aber die Exchange Server mal durchgestartet?
Kannst du mal ein zweites Postfach migrieren oder ein Testpostfach anlegen und migrieren?
Der servername welcher im Zertifikat angemeckert wird ist der Exchange 2016 oder der alte?
Nicht das er eine Verbindunf zu z. B. Public Folder Database auf dem 2010 herstellen will, aber nicht kann?
Grüße Phil
Hallo,
den bekommt der Client via AutoDiscover.
https://www.frankysweb.de/exchange-2016-umfangreiches-whitepaper-zu-auto ...
Gruß,
Jörg
den bekommt der Client via AutoDiscover.
https://www.frankysweb.de/exchange-2016-umfangreiches-whitepaper-zu-auto ...
Gruß,
Jörg
Die Migration ist noch nicht abgeschlossen - bisher habe ich nur ein Testpostfach migriert. Der alte Server (Exchange 2010) hat die .104 am Ende - der neue die .105 (Exchange 2016).
Genau deswegen solltest du dir mal folgenden Artikel zu Gemüte führenClient Connectivity in an Exchange 2016 Coexistence Environment with Exchange 2010
Btw. "@t-online.de" ??????? Habt ihr die Befugnis die DNS Einträge von T-Online.de zu ändern ?!
Von intern würde das Autodiscover ja noch mit SplitDNS und scp gehen, aber von extern nur über VPN, oder Hosts.
Zitat von @thaddaeus93:
Okay, haben den Artikel gelesen, weiß aber jetzt nicht direkt, wie das mein Problem erklären könnte.
Dann lies ihn nochmal . Irgendwann macht's auch bei dir klick.Okay, haben den Artikel gelesen, weiß aber jetzt nicht direkt, wie das mein Problem erklären könnte.
Die E-Mail werden per POP3-Connector von T-Online geholt und per T-Online Smarthost versendet.
Aua und das 2020.`Die E-Mail werden per POP3-Connector von T-Online geholt und per T-Online Smarthost versendet.
Aua und das 2020.Leider sieht man diese Konfigurationen heutzutage noch sehr oft, gerade wenn die Kunden von SBS Servern kommen wird dies oft mit übernommen.
Natürlich nicht zu empfehlen -.-.
@ frank gibts was neues?
Genau das ist in obigem Artikel beschrieben, wenn du den Artikel also verstanden hast weist du was zu tun ist 😉. Wenn nicht, Ölkännchen rausholen und den "Klick" mal nach ölen 👍.
HI Frank,
ich vermute immer noch, dass etwas in der URL Konfiguration nicht passt.
Z.B. ein fehlender Eintrag bei der Outlook Annywhere habe ich mehrfach vorgefunden, weswegen die Outlook Clients auf den alten Namen connecten.
Bitte prüfe nochmals genau alle URLs. Du hast oben lediglich drei im Screenshot ausgegeben.
Ich habe zwar gelesen, dass du es wie bei "Frankysweb" konfiguriert hast, allerdings muss irgendwo noch ein Eintrag vorhanden sein:
Was steht im AD unter dem _autodiscover SRV Eintrag?
Grüße Phil
ich vermute immer noch, dass etwas in der URL Konfiguration nicht passt.
Z.B. ein fehlender Eintrag bei der Outlook Annywhere habe ich mehrfach vorgefunden, weswegen die Outlook Clients auf den alten Namen connecten.
Bitte prüfe nochmals genau alle URLs. Du hast oben lediglich drei im Screenshot ausgegeben.
Ich habe zwar gelesen, dass du es wie bei "Frankysweb" konfiguriert hast, allerdings muss irgendwo noch ein Eintrag vorhanden sein:
Get-OwaVirtualDirectory -Server Exchange | Set-OwaVirtualDirectory -internalurl "https://outlook.frankysweb.org/owa" -externalurl "https://outlook.frankysweb.org/owa"
Get-EcpVirtualDirectory -server Exchange | Set-EcpVirtualDirectory -internalurl "https://outlook.frankysweb.org/ecp" -externalurl "https://outlook.frankysweb.org/ecp"
Get-WebServicesVirtualDirectory -server Exchange | Set-WebServicesVirtualDirectory -internalurl "https://outlook.frankysweb.org/EWS/Exchange.asmx" -externalurl "https://outlook.frankysweb.org/EWS/Exchange.asmx"
Get-ActiveSyncVirtualDirectory -Server Exchange | Set-ActiveSyncVirtualDirectory -internalurl "https://outlook.frankysweb.org/Microsoft-Server-ActiveSync" -externalurl "https://outlook.frankysweb.org/Microsoft-Server-ActiveSync"
Get-OabVirtualDirectory -Server Exchange | Set-OabVirtualDirectory -internalurl "https://outlook.frankysweb.org/OAB" -externalurl "https://outlook.frankysweb.org/OAB"
Get-MapiVirtualDirectory -Server Exchange | Set-MapiVirtualDirectory -externalurl "https://outlook.frankysweb.org/mapi" -internalurl "https://outlook.frankysweb.org/mapi"
Get-OutlookAnywhere -Server Exchange | Set-OutlookAnywhere -externalhostname outlook.frankysweb.org -internalhostname outlook.frankysweb.org -ExternalClientsRequireSsl:$true -InternalClientsRequireSsl:$true -ExternalClientAuthenticationMethod 'Negotiate'
Get-ClientAccessService Exchange | Set-ClientAccessService -AutoDiscoverServiceInternalUri "https://autodiscover.frankysweb.org/Autodiscover/Autodiscover.xml"
Was steht im AD unter dem _autodiscover SRV Eintrag?
Grüße Phil
Moin,
das Autodiscover kann durchaus nervig sein weil MS die Reihenfolge immer mal wieder ändert.
Du kannst einen Live-Test machen.
Strg gedrückt halten und rechte Maustaste auf das Outlooksymbol im Tray anklicken.
"E-Mail-Autokonfiguration testen".
Dann sieht man in welcher Reihenfolge er sucht.
Bei mir firma.de/autodiscover/autodiscover.xml, dann IMAP und POP und erst dann srv und autodiscover.firma.de.
Stefan
das Autodiscover kann durchaus nervig sein weil MS die Reihenfolge immer mal wieder ändert.
Du kannst einen Live-Test machen.
Strg gedrückt halten und rechte Maustaste auf das Outlooksymbol im Tray anklicken.
"E-Mail-Autokonfiguration testen".
Dann sieht man in welcher Reihenfolge er sucht.
Bei mir firma.de/autodiscover/autodiscover.xml, dann IMAP und POP und erst dann srv und autodiscover.firma.de.
Stefan
Morgen,
Alles Klar, schaut soweit gut aus.
Genau, wenn der Client Mitglied in einer Domäne ist wird zuerst der SCP gecheckt und danach per DNS.
Der SRV Eintrag sollte eigentlich beim installieren des Exchanges erstellt werden.
.. ...
Kannst du nochmal den SCP per Powershell auslesen und Posten.
Alternativ könntest du an einem betroffen Client testweise per Registry oder gpo den SCP Check überspringen und ihm angeben,dass er sich die Konfiguration direkt per DNS ziehen soll.
Grüße Phil
Alles Klar, schaut soweit gut aus.
Genau, wenn der Client Mitglied in einer Domäne ist wird zuerst der SCP gecheckt und danach per DNS.
Der SRV Eintrag sollte eigentlich beim installieren des Exchanges erstellt werden.
.. ...
Kannst du nochmal den SCP per Powershell auslesen und Posten.
Alternativ könntest du an einem betroffen Client testweise per Registry oder gpo den SCP Check überspringen und ihm angeben,dass er sich die Konfiguration direkt per DNS ziehen soll.
Grüße Phil
Hi Frank,
nein stimmt leider nicht ganz.
Der SCP muss auf den Server zeigen, richtig. Allerdings sollte die Autodiscover URL mit der im Zertifikat hinterlegten Adresse übereinstimmen.
Was gibt der Befehl aus?
Get-ClientAccessService | fl *autod*
Dort sollte die korrekte URL ausgegeben und falls nicht angepasst werden.
Deswegen meinte ich auch zum Test einfach mal per Registry auf einem betroffenen Client den SCP übergehen und sehen was passiert.
Grüße Phil
nein stimmt leider nicht ganz.
Der SCP muss auf den Server zeigen, richtig. Allerdings sollte die Autodiscover URL mit der im Zertifikat hinterlegten Adresse übereinstimmen.
Was gibt der Befehl aus?
Get-ClientAccessService | fl *autod*
Dort sollte die korrekte URL ausgegeben und falls nicht angepasst werden.
Deswegen meinte ich auch zum Test einfach mal per Registry auf einem betroffenen Client den SCP übergehen und sehen was passiert.
Grüße Phil